Bricks Design System Redo Cut Design & Dev Time
Brickwise is an Austrian real estate investment app, that allows users to buy shares, co-own properties, earn rental income, and sell shares on the app.
❗Problem
Initially, Brickwise had a Figma component library, but updates weren't maintained as we grew. This led to a chaotic process, earning the library the nickname "the Wild West," and eventually, these problems escalated.
⚠️ Inconsistencies in the user interface
⚠️ Inefficient, time-consuming, and repetitive work to design and develop product screens
⚠️ Miscommunication between the development team, designers and project stakeholders
👑 My Role
Conduct research, facilitate workshops, design, organize, document and train the team for optimal utilization of the design system.
⚙️ Process
😇
Stakeholder interview
🔧
Choosing the methodology
📦
Diagramming components
🧐
Heuristic evaluation
🙏
Unifying elements
💠
Figma library
T
Naming conventions
📱
The final screens
📜
Documentation
ℹ️
Information architecture
🚀
Evaluation
😇 Stakeholder interview & resource evaluation
Like every project, I begin with discovery by talking to stakeholders to see how this project helps reach our quarterly goals, I also chat with those affected by the design system and anyone else who wants to contribute.
Screenshot from Stakeholder Interview diagram.
🔧 Methodology
I dived dipper into popular design systems like Material Design, Human Interface Guidelines, IBM’s Design Language, etc, and found that the Atomic Design methodology, which uses consistent design blocks like atoms for larger elements, would suit us best.
Atomic Design example featuring Brickwise components, from components to complete page, shared with stakeholders
📦 Diagramming existing components and styles
We conducted a UI inventory to catalog unique excisting components like buttons and fields, understanding our current design ecosystem and preparing for future options.
A collection of just some of the inconsistencies found during the evaluation of our existing UI components
I found many design inconsistencies, like using 8 almost identical gray shades in one user flow and different shades for the same element on different pages.
8 different shades of grey were used, when only 1 should have sufficed
🧐 Heuristic evaluation
I invited teammates to evaluate elements using Nielsen Norman’s 10 guidelines. This narrowed down options to one or two per element after eliminating "definitely no" choices.
Each evaluator pinpointed worst offenders with industry guidelines, helping us focus on the best examples.
🙏 Unifying the components and styles
The heuristic study helped us to reduce inconsistencies, though not always yielding a clear winner. With the development team's input, I prioritized dominant elements to streamline the new design system adoption.
Selecting a color used 112 times over a similar one used only 9 times requires minimal changes to enhance consistency.
💠 The Figma library
Inspired by the Atomic design methodology, I created a Figma file where I listed the following:
• Styles: the most basic elements, like atoms in the Atomic Design methodology.
• Components: more complex organisms, mostly built using the building blocks from the "styles".
• Patterns: more specific and defined. They are built with styles and components.
• Templates: highly specific, ready-to-use complex organisms that we use quite often on screens.
• Assets: visual designs like illustrations, real estate images, etc.
• Project organization components: used to keep our design and handoff files clean and organized.
Screenshot from Bricks System Figma library
We were able to create responsive components, with all necessary states, by making use of Figma’s feature sets. While this made the initial development process longer, it guaranteed saving time in the future when designing new pages.
An example of a component
✍🏻 Naming conventions
One major challenge in the design system creation was naming. We used two methods:
Descriptive naming: For icons and illustrations, we chose names reflecting their appearance (e.g., "trash bin" instead of "delete").
Contextual naming: For other components and styles, like colors and buttons, we named them based on their usage context, ensuring consistent hierarchy.
An example of the “trash-bin” icon, which can be searched for by typing ”trash, garbage, delete, or remove”
📱The final screens
To address discrepancies and missing flows between our new designs and the app, we recreated all pages and flows, compiling them into a file named "Final Screens." This served as an effective test for our latest Figma library.
Updating the phone number flow in the “final screens” file
📜 Documentation
In the past, we overlooked documenting design decisions and updates, such as why certain features were changed and how to recreate components or behaviors. To simplify our work, we integrated design documentation into Notion, aligning with our management system. Now, we can use one tool for everything.
Since our team members were already comfortable using Notion for Company documentation, we adopted in for the Design system too
Working with the development team, we added all the information that any future designer or engineer would need to create a new design while staying consistent to our established style.
By including examples of all the features and specifications of a an element, new ones can be made that keep our established style
ℹ️ Information architecture
We divided the design system into two sections with subcategories:
Resources: Includes Figma library, final designs, and learning resources.
Documentation: Includes guides, rules, examples, code links, and archives.
🚀 Evaluation
Creating and implementing the design system had its learning curve, with issues like poor naming conventions and publishing unfinished elements. Despite initial setbacks, improvements followed. Here are the project's key performance indicators.
Quantitative succes
Design & dev time decreased by ~17%
User interface is more consistent. At least 85% of the content in our app is now built with design system elements.
Qualitative success
The design system has decreased disagreements with stakeholders about element style, size, and layout since we now have a single source of truth to reference.
Collaboration efficiency with developers has improved, and the number of calls has been reduced.
It has made it easy for colleagues from different departments, managers, and stakeholders to participate in ideation using drag-and-drop components.
The design system allows us to experiment, create quick prototypes, and test and evaluate hypotheses.
The design system has helped us scale smoothly and easily, especially when we began working on white-label solutions and desktop apps.
Learning on mistakes
After two years, we're only using the design system as a Figma library, neglecting documentation due to limited resources. We should have prioritized building the library from the start.
We regret not using design tokens, which would have saved even more time when updating the design system.
🧱You might be wondering, why “Bricks System”?
We noticed a strong connection between the Brickwise concept and Atomic design methodology: building a wall of bricks involves assembling smaller and smaller pieces. The same is true for atomic design. This inspired us to call our design language the "Bricks System".
