Design: the rendering of intent
Screenshot of Lings Cars Homepage
The act of imaging an outcome and doing activities to make that outcome real.
Design and structured content are tasks that need to be done to be able to produce a website, regardless of the quality of the design or the structure of the content.
Websites with “bad design” are still designed. Lings Cars being a famous example that springs to mind. It was an intentional decision to create a website that looks like Lings Cars does.
The content is structured and there are clear design patterns. You can see them when you look at the “Deliveries in the last week” section, these individual cars all have the same pattern. “My best selling car leasing deals!” again each car has it’s own card of intentional design.
It doesn’t take too much to imagine an outcome and do the activities needed to make it real, regardless of how ‘acceptable’ it looks, whether it is good design or not is a whole other matter.
Component driven design
Instead of designing entire pages of a website. A designer (and developer) will break the website requirements down into functional parts. A search box, a teaser, a list item, etc.
Each of these items can be designed - and possibly made - independently of other parts of the website. In an ideal world these components could also be reused between websites, but in reality I’ve found that this limits creativity and, more importantly, the functional requirements between two websites are normally different enough that they require changes.
Component driven design is great way to design and build quickly, referencing a set of patterns which can be adapted if the content or functionality is different enough to allow it to do so.
Someone who has designed several websites will be able to rattle off a list of components that almost every site has.
More complicated websites have more subtle differences between the components but it’s should be intentional differences.
A teaser which goes to an event verses one which goes to a product might look similar but they have some key differences: dates verses prices.
It’s very common to see all the components of a website within a pattern library or styleguide.
Old school Drupal developers will remember the styleguide module which printed all of the elements on to one page for an easy to view styleguide for designers and editors. Then there has been the success of Pattern Lab and a load more tools to help build a set of styles for a website.
Styleguide module (extended): https://www.ox.ac.uk/public-affairs/style-guide/digital-style-guide Component library: https://design.theguardian.com/
The way a set of components is laid out can vary wildly depending on the outcome. They might never get further than flat designs (although this is more rare these days)
A pattern library is a good reference guide for developers and editors when creating new content or features.
It exists to say “Here are all the parts of the website, if you want to make anything look different you need a really good reason why!”
A lot of people use Lego kits as a metaphor for component driven design. As a child my Lego was stored in a big blue and green plastic pirate chest and pieces would get lost, there were no instructions and occasionally there was a Barbie shoe or a Finders Keepers key.
Pattern libraries can easily become a pirate chest of forgotten treasure.
So what’s a design system if it isn’t a pattern library?
A design system will likely include a pattern library but it is a much larger and overarching [thing].
A design system should explain to anyone working on the website, or anything around it: marketing , social media, and content.
A design system will explain the desired outcome, a suite of tools, techniques, research. It will explain the thinking as to why each component is like it is, and guiding principles for creating new.
A design system is the agreed process for doing the activities which make the outcome real and maintainable - so you don’t find a Barbie shoe in your #10179 Lego Ultimate Collector’s Series Millennium Falcon.
The NHS service manual explains WHY as well as HOW but only focusses on the developer https://service-manual.nhs.uk/design-system whereas https://digital.nhs.uk/about-nhs-digital/corporate-information-and-documents/nhs-digital-style-guidelines is for content editors.
Together they are part of the NHS design system.
What does that mean in real life?
I’m going to preface this section saying that I’ve worked in agencies my entire career. The desired outcome is to make the client happy as quickly as possible, whilst managing their expectations and trying to be as agile as you can to achieve what seems to be a never ending wish list — I really enjoy the challenge of solving the puzzle and making what the client needs. It’s fast paced and you rarely get to the bottom of the wish list.
Design systems are new… well the term is, before this it was just “the design process” or “whatever it is that designers do for 6 months before a project really starts” 🙄
Essentially, they are to help people who think differently to designers understand what it is designers do.
They are to help replace team members without having to rewrite the codebase or redesign an entire section. They are for stakeholders to see that the hours of user testing wasn’t fruitless.
If you’re a product then a design system is something you can spend time refining, tweaking and developing.
If you’re an agency, it’s something you’re not going to get to build for your client. You might have a design system for how you run the process within the project, the tools to use, where to store assets, documentation, repeatable parts that don’t change between clients and allow other team members to jump in and out of the project.
It won’t be something you give to the client at the end of the project (or at the beginning where a design system should be considered)
Component driven design in reality
It feels great when you start a new project with a big list of components you need to make and a blank theme to start getting creative in, but then the frontend work starts and that agile process comes into force, things need to be built, people are blocked, stuff needs to be signed off.
There’s no longer any time to make different component designs in code, so you’ve jumped to Figma to show what you mean and get a quick sign-off on one component.
Then (and typically this is only with Drupal) something is impossible to pull from Drupal to Pattern Lab and the Twig files get in a mess, so you do it in Drupal and just like that your perfect pattern library is a mess and you’re missing some components.
It’s not to say you aren’t still designing in components, but - and the key point here is difference between the practice of designing components and having a pattern library or styleguide which is owned by the project team - is that no one has a clue which is which and what it actually does, it’s all in your head and that looks like the inside of a child’s toy chest!
In conclusion
A pattern library or styleguide will be where most agencies focus their time, if they have enough time. Something is better than nothing, but I would argue that having the principles, desired goals and outcomes and accessibility and performance guidelines written down is far more valuable than a pattern library.
Brand guidelines from a marketing team will give designers something to go on, even if it is rules to break. Pattern Libraries which are unmaintained are useless to everyone.
It’s all about having the right set of constraints and knowledge for your team to be empowered to make sensible creative decisions for the task at hand.