Three weeks ago, I started a series about design systems. After outlining my experience of what they are, I followed up last week with why they are important. This week, I’m sharing some tips on making your design system emerge into the lives of people who will benefit from your work.
A significant portion of a designer’s job is not actually designing nor understanding their end user (surprise!). A lot of the job is understanding how their work will be applied to reach said users. It’s like understanding users, only your users are your development team.
After research and time spent designing, you don’t want to risk an amazing design that can’t be built. I could even argue that if this happens, it may not be a good design in the first place. I feel that this is just as important as the solutions you work on for users.
If your vision is misunderstood or isn't supported, don’t expect others to accommodate your lack of communication. If you don’t collaborate with your developers, how can you expect them to communicate with you? It will produced the way they interpret it, which often deviates from intent. Worse, it might dismissed completely! Save everyone involved from these scenarios.
What to Include
A specialist knows how to produce materials that are usable. Static mockups of an interface are not nearly enough. The understanding of how it works, use cases, and performance considerations are part of the design. For example, a good designer knows when to use images and when to use code to design an interactive part of the interface. This decision may affect how they render the elements and specifications for the developing process. Without this knowledge, there risks an unfeasible design.
Understanding how your developers work is essential to designing a product. If you have a good grasp on how your design may applied in sprints, deliverables can be prepared accordingly. Keep the team updated on the vision. Work to prevent the need to search for the latest requirements and assets.
If you are working in a waterfall method, it may be harder to expect what developers will be working on next. Have a conversation about general order of their product development process. This will help open the lines communication both ways.
Designs should include explanations or examples of functionality. But, this does not have to be sentences of explanations. There are many ways to provide elements with specifications that serve as documentation. Sometimes, documentation may be code. Prototypes are often used as a sort of documentation because they contain changes the team learned from testing. If you’re using research and testing methods to learn and iterate, mockups will be out of date fast.
When we think of documentation we often think of formal documents or links through wikis. But just like any other project, if you think about who will be using it, it’s much easier to produce for utility. Developers often need pieces to plug in to existing systems. They also need to understand how you intend them to work together. Give them a general idea of what it should look like along with functionality in the same place.
For example, I know that even though Zeplin displays all dimensions of an element, our developers know how to code that responsively. Often this means they will only use the height, and the width will be calculated via percentage or breakpoints. I know which of these they will use in some instances, but it’s nice to not have to know every line of code too. As always, communicating as I design to make sure a decision can be executed with minimal effort as possible is important. There are many ways to solve problems, and sometimes it makes sense to change the design we’re focused on based on balance. Other times, it makes sense to revise our system to accommodate a new pattern.
Understanding the building blocks of the web jump started how I view interactions. This makes it easy for me to design with that understanding from the beginning. This is why it’s so important to have working knowledge of the implementation you’re designing for.
I like to start with a list of functionality rather than a list of elements. So, instead of saying “button”, I will write down actions such as “submit data”. This ensures we think about best ways to solve the task before we just jump into elements and get carried away with styling them. There are other ways that a user could submit information than clicking a styled button. If they were on a mobile device, we will want to serve up native controls and use the “submit” keyboard upon entering data.
This is where sketching comes in. Sketching out a few ideas for each problem you're trying to solve comes in handy for quick iteration and consideration. It also helps your brain get out of digital interfaces for a second and think about how to meet the user where they are. Do they need to use a device at all? How can we serve them at this point?
After you have your components, lay them out in a way that allows you can see/use them at once. Make sure the styles, animations and interaction patterns are consistent and meet your goals. Revisit your original research now that you've pulled your head out of style heaven. Rearrange the components into different combinations. Rearrange those combinations. Break things. Revisit, and then make a prototype. Test it with people, rinse, repeat.
Deviating from the System
In real life, there are times where you need to decide to deviate from your system. If this happens continually, you may want to rethink your system or revisit your process. Find where the disconnect is. Are business goals switching too frequently (or even communicated that way)? Are user needs not being discovered early enough? Does more time need to be set aside for testing elements before implementation?
A professional system designer constantly studies. They study user behavior, technology, technology climate, systems. A professional understands how their work affects these factors, and how these factors affect their work. They utilize considerations like those I outlined in Part I to bring a whole system together.
Atomic Design Theory
Atomic Design is a popular set of principles based on a way of thinking about design systems on the web. It helps web folks think about elements users interact with and how they fit together into a holistic system. It’s based on foundations of web concepts which can apply in the design phase. Coined by Brad Frost, his guide is available online.