The Design Challenge
Company had no central repository to refer to for user interface guidelines, components, patterns and styles. Branding, consistency, development time and the user experience of products suffered.
Benefit Hypothesis
By creating a design system and user interface guidelines in a central location all stakeholders would have easy access to and increase consistency, scalability, efficacy, speed and communication.
Our target user
By creating a design system and user interface guidelines in a central location all stakeholders would have easy access to and increase consistency, scalability, efficacy, speed and communication.
We wanted to get in the mindset of our targe user. Who are they? What are they trying to achieve? What are their biggest challenges?
Goals
- Access to all branding information in one location
- Accurate representation of individual components
- Guidance on design patterns
- Guidance on typographic styling
Challenges
- Maintaining consistency across multiple products
- Translating new component designs into code
- Understanding layout structure
- Speed of developing new features
Research, observe and understand
I organised a session with stakeholders including the UX team, front and back-end engineers, product manager and marketing to gather ideas and agree on any features and functions the design system should have and watch them work.
Front-end engineers at Thomas International need clear guidelines for UX and UI in order to efficiently create new digital products and services.
There’s no such thing as a bad idea
After discussion with the front-end engineers and product managers, I decided we would use the Atomic Design methodology from Brad Frost. Our design system would be split into categories, each feeding in the next these included Atoms, Molecules, Organisms, Templates and Pages.
Insight
We found defining our own categories for structuring the design system complex and time consuming. By following the Atomic Design methodology we could get up to speed quickly.
We could also ensure that every component and pattern we created would be easily translatable into code for the front-end team
Create and fail fast
Our main design tools when starting the project were Sketch with InVision and Adobe XD. We used the built-in design system functionalities of these tools with the idea being that all contributors on the project would be able to collaboratively add and update components.
Challenges
We quickly ran into issues with these software programs ranging from operating system compatibility, real-time collaboration and easily structured libraries.
We found that the software programs that we initially tested, Sketch with InVision and Adobe XD, did either not allow for easy real time collaboration across teams or were costly for the functionality they offered.
Insight
After more research on tooling we discovered that Figma offered exactly what we needed. We migrated the design system framework to the new tool.
Real time collaboration, top level base styles, central design system for use in all attached projects, operating system agnostic and CSS and SASS code snippets for front-end team.
Structuring the library
Using our new tool, Figma, we created a structure based on the information architecture we collaboratively outlined at the Ideation stage. This included the base styles which were available across all our projects.
Designing the first components
The design system would eventually include a vast amount of components. But to test the efficacy we started with one component type (buttons) and one pattern type (cards).
Defining styles and patterns
I created various styles of button and card components. The margins, font size, padding and various states were also all defined.
Did it work?
We now had an MVP prototype of the design system ready to get in front of the stakeholders which had all base styles and button components. Myself and another UX designer loaded up the prototype and sat watching them use it individually.
We asked questions to gain insight into what was good and what could be improved.
Challenges
Navigating an ever increasing library of components and patterns concerned the users. From this I implemented a system where we would group the buttons by type, then let users define which type of button variant they wanted through drop down lists.
I also implemented responsive components with variables allowing developers to see how the component should behave on various screen sizes and devices.
The front-end engineers took the prototype I designed and built out their own prototype using the Storybook React UI library tool. They modelled the structure on the information architecture and variables defined.
Insight
Generally users were happy with the design system. There was concern that it could get quite hard to navigate as the component and pattern library grew. We implemented a grouping and variable based system to combat this.
Fail, adjust, try again
The major stumbling blocks for this project were very much technical. Which tooling we should use took quite a while as we identified and tested options. To improve this on future design system projects, I would better identify the output needs at the ‘define’ stage of the process so there were clear constraints within which to work.
The design system is intentionally built to be an ever evolving product. Components will get added, updated and removed in an ongoing iterative process. The project overall was a success:
Conclusion
The front-end engineers can now create components and patterns confident they have the exact specification to work from
The marketing team now have a reference point for branding information and can collect visual assets for campaigns.
The product managers can use the design system components to communicate ideas with the wider company
The UX team can quickly build out prototypes to test ideas with real users
