Takeaways from the DSCONF 2018

By Tania Pasia


The DSConf was a 2-day conference dedicated to Design Systems. Talks and workshops alike aimed to bring people together to exchange ideas, solutions and inspirations and show how Design Systems (a.k.a. DS) can help build better products more efficiently.
The first day was a full immersive day with inspiring talks from 10 great speakers. This post is the first of two parts with some key takeaways from the first 5 talks on the conference day.

Jina Anne — Design Systems Anthropology



Jina Anne, Senior Design Systems Lead at Amazon, gave a fantastic talk using metaphors from anthropology. According to Jina, a Design System empowers changes in an organisation’s culture because it changes the way design is being communicated throughout. The potential benefits of a DS are:
  • Fosters a sense of belonging
  • Shows the impact
  • Enables people to be heard
  • Allows for emotional connection with others — empathy and shared understanding
  • Breaks down silos — everyone needs to feel empowered and part of the DS
  • Promotes working in pairs — for increased collaboration, mutual learning and efficiency
Jina shared a fantastic example from the movie “The Founder” and commented on the parallels of this story to the work teams do in DS. The movie shows a scene were the founders decide to shut down the business to come up with the best automated synchronisation system and layout. They drew a floor plan and directed their staff on walking paths and their tasks. They iterated, re-drew and practiced multiple times until they perfected the choreography and store layout. Their ultimate goal? To serve their customers efficiently. Efficiency with operations would mean that they’d serve their customers faster. Faster would also mean serving more customers. Within an organisation, efficiency, speed and better serving a larger number of teams are outcomes of a successfully implemented DS because it enables a systemic, organised and structured approach to design. Ultimately, Design Systems exist to support and facilitate product growth.
She also touched upon a widely used argument against DS, that of inhibiting creativity. Jina Anne’s counter argument is drawn from music, in particular jazz music with its patterns and improvisation. Jazz musicians memorise certain intervals, chords and scale patterns and apply them freely to create new melodies. This is how a DS works. Notes are the basic building blocks or ‘atoms’ of a system which can then be combined in multiple ways to form patterns that can be used in creative ways to form UI elements (existing or new).

Nathan Curtis — Systems of systems



Nathan Curtis, co-founder of EightShapes, mapped out the many connections and relationships we encounter when applying design systems at scale. He offered some great advice regarding what to do while in the process of building a DS in an organisation where multiple stakeholders have a voice. Few of the less-technical takeaways from Nathan’s talk are:
  • Acknowledge the two reasons you believe your DS will fail.
Knowing a system’s deficiencies helps teams stay realistic and also gears them towards action to overcome any inherent weaknesses.
  • Find where you are on the Step-by-Step-Adoption Model.
The Step-by-Step-Adoption model provides a great way for design teams to understand what must be done and measure themselves against something that functions as a roadmap. It communicates where the teams are heading but also breaks down items in a prioritised manner to keep all parties and teams involved on the same page. Nathan’s Step-by-Step-Adoption Model provides a clear way to showcase how adoption works, from initial commitment to full adoption via incremental achievements.
  • Understand how versioning works.
Nathan’s point stresses the ever growing need for designers to have a good understanding of how versioning and releases work, how to stay up-to-date with developments and work hand in hand with engineering teams.

Mikko Häkkinen and Rami Ertimo — A case study of Elisa’s design system



Mikko’s and Rami’s lessons learnt:
  • Kill your darlings — if something is not being used then kill it because it is probably creating more problems than it is solving.
  • Have a sales pitch — when you are pitching to various stakeholders, prepare a pitch where you present current problems.
  • Then show how a DS can solve those problems and how it can benefit the organisation. Most importantly, for the pitch to be effective, it needs to be relevant to the respective audience.
  • Be with people — talk to them and build relationships; don’t try to put a DS in place alone.
  • Consider regression — pay attention to automation, updates and quality.
  • Choose evolution to revolution — building a DS takes time; don’t just expect things will change overnight.

Kauri Salonen — Design Operations



Kauri Salonen is a Lead Strategist at Eficode. He shared his thoughts about how design can have a positive impact on the coherence & performance of an organisation. He talked about the importance of design operations and shared few tips to help leaders in organisations facilitate change and develop efficient ways for teams to work together.
Kauri suggests to:
  • Get a dedicated person, a coach with a holistic view and a diplomatic character rather than a senior designer
  • Always keep in mind that Design Operations are always an MVP
  • Start a Journal; an unstructured documentation of the inventory, the work around it and its findings. Then use it to evangelise the new way of working but also to prove to various stakeholders that the problems you are tackling are undeniable.

Hayley Hughes, Mike Abbink, Petri Heiskanen — Evolving the Design Language at Big Blue



Hayley, Mike and Petri took us through the journey of IBM’s digital transformation and shared some key insights and design practices that contributed to IBM’s robust transformation.
Hayley Hughes, Design Lead for IBM’s Design Language, described how they treated IBM’s DS as a product on its own and how important it was to have a strong DS team working exclusively on it.

“You can’t improve what you don’t measure”

A strong advocate of measuring the design language adoption, Hayley spoke about the importance of research and collecting data. Their research involved regular interviews and surveys with designers and developers — all users of the newly formed DS to collect feedback about its adoption. Using qualitative and quantitative ways to measure adoption they were able to use the insights to iterate and improve the DS as a product by reflecting upon actual needs.
Mike Abbink IBM Brand Experience and Design Creative Director, used a well know metaphor in the DS word; the LEGO metaphor. His advice was to “‘hell-engineering’ the basic building blocks of your designs; once this is in place then it is easy to use them in flexible and scalable ways while having space to be creative.” Mike also talked about typography. Digital experiences are all about typography since reading is still the most commonly used method of interacting with interfaces. Yet we have very few typography experts — a paradox that Mike anticipates will need to be addressed soon by the design community.

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 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 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

Tania Pasia

UX Designer in London | Interested in Service Design, Design Systems, IA.