I’ve already explained What the design system is, what approach we applied to the research and estimation phase. Now, we can focus on the major issue - our case study which was based on building Design System for a leading European real estate and facility manager.
What is worth mentioning - we didn’t plan to create the Design System from scratch. The idea naturally came up when the scope in all solutions that we were creating was growing rapidly. As first, we created a Responsive Web app with 3 viewports (Desktop, Tablet and Smartphone), which we named “Ecosystem”. This kind of a digital product contained:
- Booking workstations for specialists (desks, chairs).
- Booking rooms (napping rooms for relaxation purposes).
- Sensors (signalising about e.g. lack of coffee) based on a map functionality.
- Booking lockers for workers.
- Ticketing system for reporting issues.
With this “Ecosystem” we were designing apps dedicated to Android and iOS. Many solutions and constrains between them made us think and reconsider our approach in order to keep consistency not only in Digital solutions but also to be in line with the client’s whole brand and corporate identity.
A wide range of solutions, environments, design files based on many components was the first signal that it was the right time to provide our client with a “frame” that would keep all the solutions coherent. This kind of a base could be very helpful also in terms of developing further digital applications faster.
Designing complicated solutions is also connected with risks that can be reduced to the minimum once we make some assumptions. First of all, we had an internal team in the project – consisting of Developers, Business Analysts, UX and UI Designers, Product owners, PMs, Quality Engineers. On the other side, we cooperated with the client’s team (brand team, Technical support, Product Owners and people in charge) and other teams developing different solutions that could affect our work.
According to the nature of creating a Design System, the first risk that we noticed was communication between all stakeholders. Providing a new useful tool for designers and developers definitely had a considerable impact on all streams. When a Design System appears, all applications should be in line with it. Components like inputs, typography, icon set, buttons, navigations, behaviours and interactions should be implemented according to the instructions attached to the Design System. Therefore, it’s very important to make a plan of how to discuss changes with the stakeholders and also how to implement their feedback.
Moreover, gathering needs from other project teams in order to supplement the Design System can be risky because it is simply time-consuming. It would be great if the client had a dedicated team that would take care of this kind of product. Knowledge sharing and change documentation are very important to keep all provisions in order.
Don’t forget about licensing. We used the already existing tool to support the Design System. It's related to pricing (regarding extending the user’s access) and licenses. If you don’t use an open-source font, remember about typography (font family) usage. For managing workflows, you can also use VSTS, Jira or other tools.
Another risk is communicating updates and new versions of the Design System to all vendors as well as updating all code snippets and design to keep it up-to-date. How should we do that? What kind of impact do our changes have on each of the client’s solution? We have to answer these questions before we start creating a Design System.
The risks mentioned seem to prove my thesis that Design System is a product that should be maintained and… that never stops growing up.
Assumptions and goals
We wanted to finish our work and deliver the MVP in 6 weeks. We worked in 1-week sprints, and every Friday we had a demo for the client. The assumptions for this new product that we are talking about were as follows:
- Fixed-price budget.
- Specific time (deadline - 6 weeks).
- Design System based on defined user stories (we had to choose components - code snippets, which will be placed in the design system).
- We work on the already developed designs and workflows. We redesign and enhance them and make documentation with use cases.
- Because of the short deadline, we use the already existing tool for managing a design system (from our point of view, it was a better approach than creating a Content Management System from scratch).
During the estimation and research phase we assumed our goal:
"The goal of implementing the design system for our client was to create a tool allowing to reuse components, build solutions faster and be consistent in the future”.
Obviously, it’s not easy to deliver a Design System within 6 weeks, but of course it’s possible if one has a supportive team as it was in our case. I can honestly say that great people deliver great solutions. As always, the team composition is very important. Our core team consisted of:
- UI Designer (for 1 fte),
- UX specialist (for 1fte),
- Front-End Developer (for 0,7 fte),
- iOS Developer (0,3 fte).
The support team consisted of:
- Project Manager,
The above roles were described in the previous part of the article. Having those people in a team, we began a great 6-week journey with a Design System.
At Objectivity, we create user-centred products and services for everybody (not always IT guys!) and it’s worth remembering to provide solutions in a clear way and discovering who our recipient will be. While Mapping recipients, we can use a design thinking tool - ‘’stakeholders map”. This tool could be very useful in terms of showing (in a very simple way) all the people involved in projects dedicated to our client’s solutions. As creators, let’s not forget about a design thinking approach! Creative methods could be very useful in speeding all processes up. In our case, we’ve mapped the stakeholders:
- Client’s Brand team (marketing, branding),
- External Softwarehouse responsible for iOS and Android App,
- External UI designers,
- Client’s Product Owner and business people in charge,
- Internal software developers responsible for web apps,
- Creators of the design system.
How is it built?
If we talk about a Design System, we can see designs library (UI Design), Content Management System (CMS) - which is the heart of the product, Code repository (with code snippets) and of course, stakeholders (users of Design System).
1. Sketch (UI Design)
At Objectivity, we work in .Sketch - flexible software dedicated to creating hi-fidelity User Interfaces and Axure – a solution for UX Designers to present wireframes and user flows. Our design repository was created as symbols and nested symbols placed in the artboards in .Sketch and it was obviously a starting point and the base.
The workflow was very simple. Based on the previously made backlog, we declared a sprint and started working on tasks.
A UI designer made all the chosen components in the software mentioned above. Then, we made an integration with the content management system. Our User Experience Specialist made a documentation, described the behaviour of each atom. We made measurements of paddings, margins, font weights of all components. Next, Developers started their work - creating code snippets.
At the beginning they were stored locally, but finally we also created a demo for the real usage of each component. So till this moment, we have artefacts such as a Sketch file (a base), documentation (CMS) and code snippets. On the other hand, we also prepared an illustration pack and an icon set in. What is worth mentioning, the icons prepared by designers should be made in a proper way, ready for conversion from vectors to the font. Icons converted in this way are available for scaling and colour changing from the perspective of front-end developer.
2. Content Management System (CMS)
The most important aspect for us was to find a ready-to-use tool that would allow to integrate designs with the content management system. There are many alternatives for that issue (https://www.producthunt.com/posts/design-systems-repo), but you have to choose a proper one which will fit your assumptions. We chose one of them (that provides useful functionalities to help us deliver a product in 6 weeks), and we started creating a Design System.
CMS as WYSIWYG* and integrated repository allows all users with the granted access to build a design views very easily (by just dragging and dropping components from the CMS to other .Sketch file). From the designer’s perspective, it was a brilliant solution, but still - we had to find a solution for developers. Every design should be reusable and ready to code, so code snippets were the next milestone to be achieved.
*WYSIWYG - An editor that allows you to see immediately what you’ve changed in the document, but you don't see the program instructions in the form of the source code.
3. Repository with code snippets (dedicated to iOS, Web)
While creating the Design System, we had a goal to make the repository easy to manage not only for the designers but also for the developers. At the beginning we used Microsoft VSTS as our small repository to storage the code. However, in case of implementing dynamic, Angular components, we decided to move all the developed components into another place. We named this environment as “Demo”. This simple web-based tool contained a “menu” of all the components (both, iOS and web) placed on the left side as well as the presentation of each component in the heart of the website.
When users explored the design system via CMS, they also saw a link attached to the “demo”.
In this demo we showed an interaction with a UI element and provided instructions on how to change a design into a code. It was useful for the stakeholders (designers, developers) to see the real usage of each component.
The idea was the same as in the case of Web solutions. Our developer needed a repository for a code storage. For this case, we used Azure DevOps, but Github or another repository can also handle that - it’s obvious. We created a demo and provided cocoa pods as a standard in case of sharing a code library.
It also enhanced installation, updating and management of iOS-based code library. Let’s see how it works:
As you can see, UI components were not the only artifacts. We also created a repository for developers, which contained technical instructions, previews of all the components we had made as well as usage documentation.
Let’s sum up the process of building a Design System phase. First of all, it was an amazing journey for the creators. We held discussions, had win-win situations and tough and busy (but valuable!) time. Secondly, we developed a library and repository for technical specialists - both designers and developers. Our artifacts contained dynamic Angular packs with a code presented as parts of a website, graphic files for designers, illustrations, components’ descriptions and an icon set. We described interactions and behaviour of each component. Finally, we created an environment with full documentation, and we provided an easy access for the stakeholders involved in creating new digital solutions process.
This is the fourth part of a series of articles describing a Design System. The first part (benefits and weaknesses of a Design System) can be found here, the second - research phase is described here, and the third part about an estimation phase can be read here. The last part about conclusions and reflections after the design system implementation can be found here.
Have you got experience with a Design System? Share your thoughts!