Takeaways from the DSConf (part 2/2)

Helsinki, March 14th, 2018

This is the second part in a two-part series on takeaways from the DSConf in Helsinki. You can read Part 1 here.

These posts provide an overview of the topics covered during the conference. The intent was not to critique what was presented but to share and hopefully give the opportunity to a wider audience to get the inside scoop.

Adele Asuncion, Kai Forsman — Nordea case

For the past 2 years, Adele Asuncion, Senior Designer at Nordea, and Kai Forsman, UX Designer at Futurice, have been involved in Nordea’s digital transformation process. They shared useful insights from their observations so far on how applying design thinking can help a large, multinational organisation manage change and transform. As a first step they suggested to take a step back and get a bird’s eye view of a company’s product offerings. This helped them get a holistic picture that allowed them to appreciate how much design and product fragmentation exists. Another interesting point raised was about silos being a naturally occurring phenomenon in organisations; the bigger the organisation the greater the chance of silos being created. “Watch out for silos because they will contribute to a fragmented experience of your products”.

They brought emphasis to DS being the catalyst for organisational transformation. In the Nordea case, the design team used the system to leverage design thinking within the organisation and improve communication across various teams.

Karri Saarinen — When we use systems

Karri Saarinen, Design Language System Lead at Airbnb, gave a fantastic talk about how the design team at Airbnb has been systemising UI design & development and explored some new methods they’ve been using on building and operating their own DS. Karri commenced his talk by explaining why Airbnb uses a DS in the first place.

Reasons why Airbnb uses DS are:

  • Increased product complexity (and this is not going away)
  • Faster development cycles
  • Maturing of the market platforms
  • Scale of the digital process and teams

Airbnb adds to the list of companies where they have a dedicated team being responsible for building and maintaining a DS. Karri’s suggestion was to start small — establish a number of common components and re-use them across products and platforms. The Airbnb team calls these components “primitives”. When the functionality and structure is the same the teams can re-use the same component even in different contexts. Then when they need something new they can create it using a combination of the already established primitives.

According to Karri, two major challenges of DS implementation we need to be aware of are maintenance and measuring success. Having objective measures for success is a very difficult task. One measure used by the Airbnb team is tracking the number of final products/features using DS components. In other words, the Airbnb DS team is tracking how many of the final designs are using components from the core components (i.e. components designed by the DS team) vs the team components (i.e. components designed by other design teams in the company) and placing those against some predefined criteria for success.

The final part of Karri’s talk was an exhilarating reference to the future. What is the future of design? How will advances in technology impact the way design teams operate? Karri talked about creating user interfaces from drawings. Advancements on machine learning will be used for the creation of new tools that will turn sketches and drawings into actual code. He talked about parametric design and how in a few year’s time we will be moving beyond drawing rectangles on a canvas.

Niko Laitinen — Sustainable design systems

Niko Laitinen, Designer at Nitor Creations, touched upon the importance of understanding a DS’s long term life cycle. He emphasised how crucial it is to know the pitfalls of your DS and constantly working on answering the question “How can I keep my Design System alive?”. When it comes to defining a DS, Niko argued that “A style guide is an artefact of the design process whereas a DS is a product serving products” agreeing to Nathan Curtis’s views earlier in the day.

“Do I need a DS?” is a question he gets asked a lot. The answer is “It depends”. For growing companies DS are important because having a system in place helps them scale efficiently.

Josh Brewer — Version control for design systems

Josh Brewer is the CEO at Abstract, a tool providing a secure, version-controlled hub for all design files. Josh talked about how they’ve been using Abstract to design Abstract and shared valuable insights from learnings so far. He spent some time portraying common use cases of design teams using obsolete ways of communicating updates or changes on designs that hinder progress and productivity.

Nowadays, a common theme many companies are trying to address is “How do we move faster?”. Josh’s answer to that is: “Work smarter”. He recommended putting a DS in place that uses version control. Some of the benefits of having version control in the design process are:

  • Is a repository of knowledge
  • Is all about transparency
  • Is collaborative by default
  • Allows for teams to manage control over time
  • Protects the work
  • Helps to make the transition from ‘me to we’
  • Fosters communication
  • Uses concepts like branches — commits are moments in time when you collect moments of work where you give meaning
  • Gives context and make changes publicly available

Roman Musatkin — Design system for a full stack team

Roman Musatkin, Product Designer at Smartly.io talked about his experience of building a DS in a growing dev-driven company. Some of the benefits of building a sustainable design system are:

  • helping design teams to prototype and take design decisions faster
  • improving collaboration between designers and developers
  • empowering everyone to contribute to better design
  • creating better experience for customers

Here are Roman’s 5 tips for building and maintaining a successful DS:

  • A great DS evolves — it is not set in stone.
  • Design teams need to find ways to control change. Change is the default state and designers need to cater to it.
  • Keeping the system up to date is pivotal, which means conducting regular reviews of the system is advisable.
  • When designers take design decisions themselves upfront, engineers don’t have to spend time thinking about; which leaves them with more time to work on engineering challenges that’s interesting to them.
  • Providing guidance to developers during the implementation phase helps keep everyone empowered to contribute in building better products. The design team is tasked to produce design guidelines that are shared within and across teams. For instance, at smartly.io designers and developers alike know that when users have unsaved data, the system should always ask users whether or not to proceed. They’ve also created guidelines for the tone of voice to be used across the UI to keep it as consistent as possible, regardless of who is implementing the updates/changes.

Brownie points!

Here are some great resources for further reading and inspiration shared by the speakers.


  • Design Anthropology by Alison J. Clarke
  • The Whuffie Factor by Tara Hunt
  • A Pattern Language by Christopher Alexander


  • designsystemsbook.com
  • publication.design.systems
  • news.design.systems
  • coalition.design.systems
  • design systems slack channel
  • stylebook.elisa.fi
  • https://github.com/airbnb/Lona
Like what you read? Give Tania Pasia a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.