If you are familiar with us, or have read any of our other content, then you probably know that Acquia Site Studio is our weapon of choice for building and maintaining Design Systems in Drupal. It’s a low code solution that integrates seamlessly with the Acquia stack, and it has allowed me as a designer to create reliable, reusable and scalable solutions for our global clients.
Now when it comes to actually designing the systems for Site Studio, there’s two things us designers will need to do:
- Design the front end solution - nothing new here
- Design the CMS editing experience and make sure it’s near impossible for a content editor to break the defined rules of the system
The second point adds an additional layer of thinking early on in the design process. As we’re busy beavering away on low fidelity mockups, we also need to start thinking about our components and start defining atoms, molecules, organisms and templates (if you have no idea what I’m talking about here, I’d recommend checking out Atomic Design Methodology by Brad Frost).
As much as possible, we need to understand what areas, and to what level, a content editor will be looking to edit these atoms, molecules, organisms and templates. This is so that we can define each touchpoint on their journey. Should this heading always be a H2? Will the image always display on the left or should we be able to swap the image/text order? How does this atom adapt across 20 different brands?
Because Site Studio is a low code solution, all of the changes mentioned above will be done by the content editor through the Site Studio UI, not by a developer. And when it comes to defining the level of UI flexibility, there’s usually two camps:
- Lock it down
- We want the power
As you’ve probably realised, there is no ‘one solution fits all’ here. Finding the sweet spot can be tricky. Depending on project scale, number of teams involved and technical knowledge, the solution and the Site Studio UI will vary from project to project. So where do you start? Well, from my point of view, with these 5 UX laws fresh in mind.
1. Hick's Law
The time it takes to make a decision increases with the number and complexity of choices.
Think carefully about any option you choose to expose to the content editor. A request or two that might not seem like a big deal at the start will quickly add up, and before you know it you might find yourself in a sticky pickle with a super flexible UI that is on the verge of overflowing with settings. Ultimately, more settings means less defined rules for designers, more training required for content editors, more room for deviations and maybe most importantly - longer time to market.
2. Jakob's Law
Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know.
If it ain't broke, don’t try to fix it. Is it really necessary to create a branded experience for a date picker, or is the browser native date picker more than enough? Ask yourself if the effort required to implement something matches the value it gives the end user. If it doesn't, you might want to save your efforts and focus them on something that does.
3. Pareto Principle
The Pareto principle states that, for many events, roughly 80% of the effects come from 20% of the causes.
To maintain consistency and usability, and to avoid bloating the system, it is inevitable that some areas of the design system will need to be standardised. Especially for multi-brand solutions. Focusing time and resources on the areas that will bring maximum value to the most users is usually, if not always, a better approach than trying to cater to every little snowflake and edge case.
4. Postel's Law
Be liberal in what you accept, and conservative in what you send.
This is where understanding the needs of the content editor really comes in handy. As feature and change requests come in (and trust me they will) remember you’re the guardian of the system. You understand the product and the bigger picture when others might not. There’s nothing wrong with pushing back and challenging the requests if you can see that usability and scalability is at stake.
5. Tesler's Law
Tesler’s Law, also known as The Law of Conservation of Complexity, states that for any system there is a certain amount of complexity which cannot be reduced.
There’s always going to be instances where you can’t avoid some parts of the solution being more complex or clunky than you would have wanted. Some third party integrations will come with limitations that we have to accept. If you plan for this, and make sure the rest of the system is tip top, one or two of these will be easier to accept.
So what do these 5 UX laws have in common?
They all boil down to consistency and usability. In my experience, the scale of the design system doesn’t necessarily define the complexity. Keep striving for consistency and always make sure you maintain usability. If you can manage those two, you are well on your way to creating a successful product.
Author
Sandra Södergård
Sandra is a Senior Solution Designer and has worked at Coherence Digital for over 4 years. During her time at Coherence Digital, she has overseen multiple design system projects for global clients.
Get in touch
