A few months ago we read about design systems. Some designers thought that it was a Sketch library with well-prepared components, while other developers thought about an expanded style guide. Project owners and IT people considered a design system as other graphics prepared for development. And those people were right - design system has all the integral parts mentioned above.
But based on what you can find in the previous parts of this article series - a design system definitely is another product which keeps other digital solutions connected and coherent. It helps to develop new functionalities and applications faster! So, this is why we think of a design system as a complicated, robust project.
When the design system was released...
Having released the product, we were very excited about the user’s reaction. And it was what we’d thought it would be. After we prepared the design system, reactions were different. So different! A huge responsibility for developing new applications based on our work. We didn’t expect so many questions from all kinds of specialists. We’ve received many insights and comments on how to improve the product. Yet, it is impossible to predict all cases and possibilities within just 6 weeks. And the best issue related to design systems is that as we're developing this real and complex product (such as Design System), the project itself is subject to expansion. But when we see new solutions that are in line with the idea developed by you and other creators of design system – it certainly keeps us moving forward.
Let me introduce the most important issues we’ve experienced.
#01 is it really necessary?
After 6 months from the Design System release, we are able to answer this question. Well, it depends. It works in our case - other designers, from different teams, can easily copy and paste the User Interface elements. They have documentation, specifications and use cases of atoms, components, layouts. The development was speeded up thanks to the code snippets library, which was already prepared and ready to be implemented. We were proud of creating a place where designers, developers and business people can work, implement and read about components usage. Most importantly, we created an environment where all designs - components, modules, layouts were in order: categorised, described, measured and presented as a real case.
#02 Is it worth creating?
It goes without saying that it’s not easy to share knowledge between users, and additionally - new people in the project are not really keen on design systems. Why? I mentioned that aspect in the first part of the article series - the entry barrier turned out to be a huge issue. We reduced UI designers’ creativity - it’s true because we imposed a design method for specialists that will be taking care of further solutions. We also reduced the User Experience research phase (because we, as the creator, did all the research in our own way). On the other hand, we provided well-prepared components and ready-to-use modules according to good practices. What we can say - from a business point of view - it’s worth providing such a solution because we increase efficiency, reduce development costs, and provide quality and control. From the design perspective, we can also have much fun. Well-prepared designs are always an added value because a specialist that takes over the project can focus on enhancing a project - there is no need to focus on basic issues that we included in the Design System.
#03 What about us - creators?
It’s obvious that time pressure and a lot of tasks to be handled were not easy. Confronting the development world with design and User experience can provide amazing conclusions. Because we wanted to create real, working solutions, not a utopian world. Moreover, the possibility of discussing our area of the specification was brilliant! First of all, we had daily debates and we refreshed our knowledge of mobile and web solutions. It’s not easy to match iOS behaviours of controls and present them according to web technology (different ways of scaling typography, colour values, form components specification, Apple’s guidelines as HID). Secondly, working with a team on creating a Design System consolidates your knowledge and shows that creating real working solutions brings cooperation and develops standards. It also provides understanding based on matching development with design. There are many articles about “wars” between designers and developers in terms of the whole design process - it's not possible to approve of that in a Design System! Refilling our competences pushed us into moving forward! Finally, after creating a design system, we can frankly say that it’s a myth. Understanding different points of view (technological, conceptual) is the key to success!
#04 Confronting users’ feedback
We’ve received so many insights and ideas from stakeholders of how to improve a Design System. Also, we discovered so many bugs (thanks to our tester’s patience and watchful eye!). Creating such a complicated product definitely requires an open mind, otherwise the project can be written off.
What we have to keep in mind: design system never ends - there is always room for improvement. Let’s listen to the users and make our design systems better and better. Because we design for people, not for the idea!
#05 What’s next?
Personally, I’ve got my favourite answer - it depends. While creating a Design System we used .Sketch software for designs, Angular solutions for code snippets, and in iOS - native behaviour for mobile solutions). However, we have to bear in mind that technologies keep growing and developing, and so is our knowledge. Perhaps, in a few months we will have to reconsider our decisions? Therefore, the best option is to keep working on the product, develop a Design System and introduce solutions to new stakeholders, take care of communication and receive feedback from them. In my opinion, being a dedicated team is the best way to improve skills and to take care of the brand’s consistency.
Yet in our case, the responsibility was to create a Design System, and in the first stage the goal was to present it to the clients and their team. The second stage was for the project to be taken by our client’s specialists. So, as I’ve mentioned many times in the previous parts of the article’s series - we had a timeline, budget and team. We prepared a fully working environment and… and that’s it. The job we did was an amazing journey, but now our masterpiece lies in the client’s hands. We keep our fingers crossed for successful management and development of the Design System in the future.
There is always room for improving digital solutions. Technology is changing, software is changing, and so are the standards and trends of designing components. Such changes are best in the IT sector - an agile approach, where we have to think about the future and match our decisions with the situation. What was most important for us - we verified the usefulness of the design system on a real case - it’s definitely not a buzzword! We have proven that, with this type of product, we care about the development of the client's brand as well as its digital applications.
* * *
This is the last 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, the third part about an estimation phase can be read here. Our case study for a leading European real estate and facility manager you can find here.
Have you got experience with a Design System? Share your thoughts!