By way of introduction

In the previous article, we discussed the strengths and weaknesses of having a Design System as a product – and our client seems to be eager to build this kind of solution. In a utopian world, with an unlimited budget and a number of designers, developers as well as the client’s knowledge of the product, we can boldly go ahead and initiate a project. However, in the real design world, rarely do we find ourselves in such favourable conditions. Therefore, in the early research stage, it’s worth taking into consideration certain restrictions:

  • If the project is financed in a Fixed-Price* or Time-and-Material** model?
  • If we create the product from the very beginning or if we apply ready-made solutions? If so, what are the restrictions? If we are building the whole system by ourselves – what challenges await the designers?
  • How many and what kind of stakeholders need to be engaged in the project? What is our goal?
  • What should the project roadmap look like?
  • How would we solve project management and maintenance after the implementation?

I would like to answer these questions by introducing you to one of our use-cases.

Fixed-Price vs. Time and Materials

The approach towards settlements is quite important as we need to allocate our budget and assign specialists to their tasks within a limited timeframe.

Fixed Price requires the settlement for the whole project to be made in advance, while the very deadline of the project delivery is quite short. That is why it’s important to skillfully allocate the man-hours among the specialists (knowing the roadmap and choosing the tools or the way of creating the system beforehand). A project prepared in the Fixed-Price model should be thought through, have the exact schedule and meticulous scope of tasks.

According to a more flexible settlement model – Time and Materials – the client has a general knowledge of the product, but at the same time, they are not ready to specify the backlog (tasks scope) and the implementation schedule. The client pays for the work that has been done to date and does not cover the flotation costs.

Design System built from scratch or using the existing solution?

Once, when building a Design System for our client, we faced the following challenge: Should we build the Design System from scratch by spending more time on “wrapping our product up” and creating some kind of a content management system (CMS), or should we use a solution already existing on the market and focus on the very content creation?

On the one hand, system built up from scratch may be based on tailor-made solutions and contain, i.e.:

  • Admin, moderator, editor function; third party having only a content preview.
  • Possibility to allocate particular roles to the users.
  • Functionality of adding descriptions, source code, source images, content preview.
  • Possibility of adding and intuitively displaying the source code and components.
  • Possibility of adding visualisations and videos to the content description contained in the Design System.
  • Security and the ability to share content with a particular user.

On the other hand, there are lots of already developed solutions on the market, which have the above mentioned functionalities. We need to keep in mind that ready-made solutions may have some restrictions (i.e. lack of possibility to edit core functionalities), unlike the system built up from scratch. Let’s not forget about integration – displaying and downloading the source code, project files for designers etc. In the already developed content management systems, we avoid the long process of designing everything from scratch.Therefore we can focus on the content that is part of the Design System. Let us compare the already existing CMS solutions that may help us design a Design System itself and build such a system from the ground up.

Table 1) Approach to creating a Design System

What is more, let’s consider a few important things. Does the client already have some digital products? If so, will all the rules, behaviours, and interface elements (included in the Design System) concern all the existing applications? Or perhaps the next emerging applications, which are to be created after the implementation of the Design System will be consistent with the above mentioned rules, behaviours and interface elements?

Let’s not forget to review the client’s previous projects, because they will also be affected by the Design System – it is not easy to obtain a consistent behaviour and design of digital products. When introducing a Design System, we need maximum commitment from our client.

Stakeholders in the project

Those directly involved in the Design System are internal stakeholders: developers, graphic designers, UX designers, PM, testers, and in the early stages – people responsible for sales.

However, let’s remember that a Design System can be created not only for our own purposes. Our external stakeholders could be those indirectly working on creating digital products  – agencies/companies which cooperate with our client – our Design System will also apply to them.

It would be worth considering which specialists will be necessary in the project and what their involvement will be like. When it comes to Design System Creation, companies well-known in the Design world propose, e.g.:

  • Having 2 UI designers, 2 UX Designers and 1 developer
  • Team composition based on: 2 UI designers, 1 UX Designer Developer, Tester, PM
  • 1 UI designer, 1 UX Designer, 1 Front-End Developer, 1 Mobile Developer, Tester and PM

Let’s imagine how much workload and how many resources and people involved are required to create a large-scale Design System.

There are lots of combinations of complementary specialists, and all this depends on how complex the product is supposed to be. For example, if we would like to create a Design System based on mobile applications like Android or iOS, it would be worth having a UX Designer and UI Designer in our project (apart from Android and iOS developers of course). If it’s going to be a product used by many stakeholders, it may be worth including a Tester and a person responsible for project coordination. Together with the Design System scale going up, the project team increases as well (Captain Obvious!)

What kind of resources would we like to provide? Who will be the recipient of our product?

Before we proceed with the very creation of a Design System, it is important to gather all the necessary knowledge from our client: how and in what circumstances they are going to use the product. It is also worth asking about the subcontractors. It is quite possible that the client’s ecosystem consists of lots of stakeholders. One agency delivers mobile apps, another software house delivers a web application, the next one provides another design, while the other subcontractor takes care of branding and marketing.

If it is possible, it’s worth asking about:

  • Design process – How are the source files created? Photoshop, Sketch or perhaps Framer, Figma or Adobe XD?
  • When developing a Design System, which will contain source files easy to edit and duplicate, it would be a good idea to find out what kind of graphics software our client’s key stakeholders use.
  • What kind of technology is used by developers? Will other subcontractors find it easy to duplicate tell-tale (which we prepared in the Design System)?
  • How do Android and iOS developers communicate, share the elements and source code?
  • Where do we prepare a Design System? Would it be possible to create a repository of duplicative elements available for every platform and to every subcontractor?

Gaining knowledge about the environment and the client’s subcontractors is of key significance as we do not create a Design System for our sake but in order to help the client develop intuitive and user-friendly digital products.

What will the project road map look like?

Before the design process begins, it would be worth discussing the way of communication with our clients. A well-organised work schedule will prevent us from having unwelcome misunderstandings, and will ensure a smooth workflow.

At this stage, it’s worth answering the following  questions:

  • What kind of resources will a Design System consist of?
  • What elements will be of top priority? (It’s quite obvious that we are not going to provide, e.g. all the existing tell-tales, and that’s why we should prioritize our resources and set a backlog we are able to complete within a certain budget and time).
  • When can we show the effect of our work to the client (MVP***)?
  • What will the maintenance look like after the product release?

It’s also worth preparing a brief schedule describing the project stages. For a few-week, short project, such a plan could look like this:

  • 1 week: setting priorities among the pre-prepared backlog with its clarification (LINK), Visual Language Design on the level of Visual Design and UX; colour, typography, basic tell-tales prepared in .Sketch file (let’s keep in mind that design should always be one step ahead of development!)
  • 2-4 week: further designing on Visual Design and UX level; front-end and iOS developer join the project; creating MVP version; creating components from the atoms
  • 5-6 week: designing components of lower priority; a software tester joins the project

After each sprint, the team should present their work to the client and keep them up-to-date, e.g. using the Gantt’s diagram.

Product management and maintenance

The individuals preparing a Design System have the largest amount of knowledge in terms of digital solutions development. On the one hand, a Design System creator is familiar with all the components, colour, typography, icons and other interface elements. On the other hand, developers – both front-end and back-end – would have to somehow handle pushing particular components into the repository and ensure their duplicity.

Therefore, people who had an impact on the Design System development might be of great assistance and support at a later stage of project maintenance.

Consequently, it is worth considering which specialists will be responsible for maintenance and for:

  • Support
  • Answering (frequently tough) questions from subcontractors
  • Additional design of missing elements
  • Consultations and project coordination

Conclusions

As I’ve already mentioned in the first part of the article about a Design System, it is a product that needs to be taken care of throughout its whole process.

A product abandoned right after its implementation will be written off and doomed to failure. It’s worth mentioning this fact to the client before you even begin working on this venture.

Moreover, another aspect to be taken into consideration is whether we are going to use the services of a company offering a solution to “wrap up “ the Design System, or whether we are going to build it from scratch. There are lots of differences, as well as advantages and disadvantages of the above mentioned approaches. In order to meet the challenge, it is crucial to set a budget, resources and time within which our Design System should be created!

* * *

This is the second part of a series of articles describing a Design System. The first part (The truth about design system — benefits and weaknesses) can be found here.

Have you got experience with a Design System? Share your thoughts!

At Objectivity, Design is our passion and we share our work not only on Dribbble but also on Behance. Explore this world with us and see our daily life on Instagram.


* Fixed-Price settlement made in advance for the whole project usually has a short deadline.

** Time and materials (T&M) is a contract for construction, product development in which the employer agrees to pay the contractor based upon the time spent by the contractor’s employees and subcontractors employees to perform the work, and for materials used in the construction process.

*** MVP – (The minimum viable product) – The idea of an MVP is to get user feedback before developing the final product