I mentioned the advantages and challenges of a Design System in the first part of the series devoted to Design Systems. I also presented a brief insight into research phase in the second part. Today, we will look at the thread of estimation – involvement of individual specialists in the project as well as determination of the initial project backlog.
For the purposes of the article, we specify that our MVP should be closed in 6 weeks while operating in 1 – week sprints ended with a demo for a client (based on the Fixed-Price cooperation model). It is worth mentioning because in the next part of the article you can find, e.g. the exact timeline based on those assumptions.
It is very important to choose the right specialists for such assumptions. A dream team responsible for design system creation should consist of designers (both UI and UX) and developers. Such specialists have expertise in research, design and coding that are necessary to deliver high quality digital library. Last but not least, it would be great if the team had experience with Design Systems. Our team composition consists of:
- A UX Designer who is responsible for usability issues, apps reviews and selection of components that should be implemented to the Design System. He or she also takes care of the user’s behaviour and solution scale.
- A UI Designer provides consistency in the design language and delivers all visual aspects of the design system. UI Designers make things pretty, catchy and user-friendly.
- A UI/iOS Developer is responsible for coding and delivering code snippets
- A QA Engineer is responsible for checking bugs and signalizing discrepancies between the design and implementation).
- A PM helps to organize workflow and takes care of financial issues.
What’s more, in the above composition we also cooperated at the implementation of other digital products for one of our clients, so we worked partially on the pre-designed interface elements.
Those responsible for creating a Design System should analyze the client’s current digital solutions before the project is launched. It’s important in the estimation phase because the Design System will have an impact on all the client’s products that have already been developed. In our case, we didn’t have to start from scratch – we refreshed and selected the existing User Interface components and made them more useful. We created a Design System to help our client be coherent and to make it easier for them to exist in the digital world as a professional, well-designed brand that maintains consistency in mobile, web and print solutions.
Atomic design (Brad Frost, Atomic Web Design) is an approach recommended to follow in Design System creation. The idea is to define small User Interface elements and to use them in order to create more complex reusable components and predict each element’s behaviour in as many cases as possible.
As I’ve mentioned in the previous parts of the article, our team had a specific budget and time to implement the Design System consisting of a library dedicated to the needs of WEB and iOS applications. While defining the backlog, we used Nathan’s Curtis insights (Nathan Curtis, Picking Parts, Products & People). Therefore, we always recommend to use good practices if it’s possible!
We asked our developers to select the controls that would be implemented within a specified time.
According to the backlog, the following interface elements were selected:
WEB List of atoms / components
- Alerts (or “toasters” – components that appear on the top of the screen after the user’s action),
- Icons (with a CSS code – providing classes; avoiding implementing images; ready for converting to the font),
- Tables and pagination,
- Primary tabs, secondary tabs,
- Toggle buttons,
- Bagdes (also known as “labels” especially in e-commerce),
- Form atoms (labels, inputs, selects, dropdown, disabled dropdown, text area, calendar dropdown module),
- Buttons (primary, secondary – including states, disabled),
- Typography based on open source license,
- Colour palette (primary, secondary colours, shadows under the components).
iOS List of atoms / components:
- Switch, Slider,
- Text view, text field,
- Labels, buttons
- Border view also known as a “pop-up” functionality,
- Navigation bar,
- Activity indicator, circular progress (an interactive chart),
- Empty view (illustration + text area),
- Confirmation view (illustration + text area),
- QR code scanner view,
- Colours in the project (primary, secondary, shadows),
- Font family, font heights based on an open source license,
- Toasters (also known as warnings / alerts),
- Extensions (like navigation presentation).
The selected components were described as User Stories and were used as an input to the backlog.
We decided to use the Microsoft VSTS tool for our sprints in order to organize our daily work.
All right. We have our estimations, we’ve selected the atoms (components) and we’ve presented our assumptions to the client. Now, we it’s time to prioritise all the chosen UI elements. For example: typography, buttons, colours and checking WCAG could be our base to design more complex components. So, it’s important to design them first. For prioritization and responsibilities we also used the already mentioned Nathan’s Curtis canvas.
The next step we made is a Gantt Chart. We divided sprints, matched components, set up demos for our client at the end of each sprint (every Friday during our 6- week journey). With our Project Manager’s help, we introduced daily meetings and weekly planning (it’s essential to plan work, share the knowledge and signal some difficulties or bugs).
Summary of the project’s estimations
Let’s sum up the estimations phase. We started from the team composition – we used canvas and tools for selecting all the components of a Design System. We conducted prioritization and wrote down the list of people responsible for creating them. Then, we asked our Project Manager to set up agile workflow based on Microsoft VSTS (but of course, we can use Jira or other workflow software). We created a backlog by means of user stories and a roadmap – we used the Gantt chart tool to plan each sprint. Finally, we got a green light from our client and started creating the Design System. However, this phase will be discussed in more detail in the next part of the articles on a Design System. Stay tuned!
This is the third part of a series of articles describing a Design System. The first part can be found here: The truth about design system — benefits and weaknesses. You can also read about our Research phase here. The fourth part can be found here: Use case.
Have you got experience with a Design System? Share your thoughts!