Understanding the need for a multi-angled view of design in business.
What is the value of design? This question is overwhelmingly bounced around, not only on social media like design twitter, but also in meetings, in product teams, and in companies’ strategic steering groups. Rightly so, we all need to understand — even designers — the real value that design creates.
There are a couple of interesting scenarios that I observe dominating design in business, that happen over and over again, that make the answer for “what is the value of design?” almost impossible to justify. Design being either a function, or a partner in companies.
To understand design holistically we need to observe and operate in multiple levels identified as craft, operations, and strategy.
“Designing for the future starts with redesigning how you show up in the now“
– Mia Blume
Design is not just a function When design is reduced to simply the deliverable (as opposed to a process), it is seen as merely execution. And likely is seen as a nice-to-have. It is hard to justify the value of design then, because while pushing pixels can contribute to the overall betterment of a product, the real value of design is not shown directly through that. In similar scenarios where design happens in isolation, whether it is UX, Service Design or Design Research, unless design is seen holistically it is hard to put any value on it.
Design is not just a partner In mature customer-centric companies, design has gained a bigger role in an organizational level. Design can help in development teams, with UX embedded. Designers and developers can work more efficiently. Design can help with Design Research and aid in the customer understanding. Design can help on a strategic level with facilitation, service design and coaching. However, still, unless design is seen holistically, a compartmentalized design jumbled into silos is hard to measure.
The three levels of design
A lot of advances have been made in our profession. As Doug Powell pointed out in his closing keynote (Design at scale) at the DesignOps Summit, this is the best time for design and designers. We observe that design happens in 3 different levels and we need 3 different lenses to understand those focal points.
Design Craft
We are actively solving cross-disciplinary and collaboration issues with the wide adoption of solutions like design systems and automations. With such products or solutions we have also been able to measure clear benefits for business goals: Speed to market, cost efficiency, and cross-collaboration increased.
Design Operations
The next level of challenges involve scaling teams, not only in terms of numbers and talent but helping amplifying the design craft through design and research operations. While adopting such practices, companies are able to measure benefits that deal with: increase of product design and design research work while a specialized team take care of the operations and processes, which lead to employee satisfaction (designers doing actual design and research) and reduction in attrition rates.
Design Strategy
The next set of challenges are strategic and focus on design leadership. Keeping one eye on the horizon and one eye on the next wave (Maria Skaaden at DesignOps Summit). Design needs a strong culture, a North Star and a competent leadership that is seen as equal as the rest of the parts of the imaginary Venn diagram: engineering — business — design. Companies who have been able to achieve such level of design (climbing the famous design ladders), they see clear benefits in understanding (making the right products), delivering (making the products right), learning, discovering, and having a vision.
Yet, unless design is able to change the whole organization it fits in, in order to accommodate for all those changes it propagates for, it would likely fail because it would fall on a vacuum, and inherently design would create its own silo along the run.
“By choosing to be a designer you are choosing to impact the people who come in contact with your work, you can either help or hurt them with your actions. The effect of what you put into the fabric of society should always be a key consideration in your work“
– Mike Monteiro
Towards holistic design
As we see by now, design works in different levels and we need different focus lenses to understand the real value of design. Those three different lenses are identified as craft, operations and strategy. Holistic design is understanding and solving problems in all those levels that design operates. When we see design holistically, we understand the value design has, in its totality. A whole is indeed greater than the sums of its parts. This is also called emergence. In philosophy, systems theory, science, and art, emergence is the condition of an entity having properties its parts do not have, due to interactions among the parts.
Design has to hold a few important distinctions that makes it holistic. A holistic design approach ought to be inclusive by default. It has to be ethical and diverse and most of all it has to be people-first. With well-researched and design-oriented approaches, profit is assured because it always identifies a need and then solves it. Impact equals profit, the opposite is not true.
If that sounds complex, it is exactly because it is complex. The more you zoom out and see a profession as part of a system, we understand that wicked problems require extraordinary solutions and multidisciplinary and inclusive approaches.
Design systems are a hot topic right now. Everyone talks about them and wants to build them. It is evident that software has eaten the world, and design has a major role in this. Undoubtedly, design systems are a much needed help to scaling design and development teams.
“A design system unites product teams around a common visual language. It reduces design debt, accelerates the design process, and builds bridges between teams working in concert to bring products to life. Learn how you can create your design system and help your team improve product quality while reducing design debt“
– Design System Handbook
A huge chunk of design process is often not mentioned, when talking about design systems; design research. This doesn’t mean that teams do not perform research work when creating design systems. However, it is a subject we have to address and establish well in our processes, as our systems mature. Especially when we preach that design systems are about people.
If we integrate a well structured and documented process for design research, we would potentially see more companies adopting methods like this. It could lead to more informed and sustainable environments for teams to mature and grow.
Design Systems are products
A design system is a product within your product line that serves specific customers. Nathan Curtis points out in his article “A Design System isn’t a Project. It’s a Product, Serving Products” that applying well-established approaches for product management and product marketing is a great start.
The point here is that you cannot just design and develop a product; you have to set up processes and a team to run it and market it as well. A design system needs to have a clear line of decision making:
– Teams for heavy lifting on design and development
– Stakeholders that are responsible for things like budgeting and resources (people, tools etc)
– A clear roadmap
All these affect your design system and therefore the products that the design system itself affects. At the same time, there has to be understanding as to which products will use it and when can it be integrated, which parts each product needs, and how you ensure that the design system is well presented and demoed.
“A style guide is an artifact of design process. A design system is a living, funded product with a roadmap & backlog, serving an ecosystem“
– Nathan Curtis
Why some Design Systems fail
There is a plethora of Design Systems out there. Some of them have matured and become the point of reference for teams trying to create their own success stories in the field. But still to this day many design systems are built and forgotten, or fail and get replaced, or become vaguely outdated as products race in a ‘growth frenzy’ tech world. You can imagine the cost of something like this — how wasteful and unproductive it could be.
Many of those failed design systems are an outcome of many pathologies within a company. Teams end up working in silos with no open collaboration or clean ownership, or there is simply no adoption for your newly created design system. A big part in a failing product more often than not, is an improper understanding and lack of research. In this article, we try to remind ourselves of the established research methods we can use in order to build a design system that teams and products will benefit from.
“As with any product design process, it’s important to do your research. (…) Your design system will get used much more often if you create it to fit into the workflow of other teams“
– Jina Anne
Defining your research scope
The process of research in design teams follows the already well embodied research methods of many social science branches such as anthropology, psychology, sociology and linguistics. The choice of research methods depends on the questions a team wishes to answer at the time, but they contain both qualitative and quantitative methods to gain a wide understanding of customers.
– Qualitative research methods: concerned with the human behaviour, and why people act the way they do
– Quantitative research methods: collect numerical data based on users actions.
– Analysis: based on the research methods you choose, analyzing research data can differ. For example, for qualitative results you might consider content analysis because most data is generated in some form of narrative and comments by the researchers. For quantitative results, statistical methods may apply in order to understand and identify patterns in users actions.
It is fair to mention that that many companies that agree to build a design system, will not necessarily allocate dedicated research resources. The tasks might fall in the lap of the people who are actually building the design system, or external help like consultancies.
1. Understand the background In order to start the research process, background work has to happen. With that work, the research team tries to map the current ecosystem and understand the parts that will be affected by the design system. Once they identify different user groups (designers, developers, and the rest of the stakeholders), they study their interrelationships and at what level they communicate with each other.
It is important to identify potential silos that might exist, and what levels of communication exist among them. This is because design systems often work in the favor of breaking those silos and align teams better.
While studying the teams, the research team can identify and map all the different technologies that teams are using:
– Current technologies used
– Potential solutions that have been studiedImmediate challenges that current/future technologies bring
– Opportunities that can exist with the adoption of more efficient tool set
On a broad scale, they try understand the life cycle of the design system. Where did it start? What previous attempts were made to study the teams? What tools did they use? What lessons were learned? Additionally what does the roadmap for the future looks like, with the maturity of the current products and the addition of future products?
Furthermore mapping the opportunities for adoption, it will be beneficial to understand what are the potential highly used or sought after components that would need to be in the design system first. This will speed up the adoption of such system once implemented.
At this point, the team has written a lot of notes on the observations of the teams, their background, their relationships, and their roadmaps. There should be a plethora of questions coming to mind regarding all that background information. And the next step is to take the questions you have and start planning on interviews.
2. Define the research questions The team is planning and carrying out interviews with key people from the company teams identified. It is equally important to identify the questions that the users themselves are looking to answer. Those questions and answers will inform how and what things are being built in the future.
Company teams identified
– Designers & developers who will use the design system
– Designers & developers who will build and maintain it
– Marketing & branding stakeholders who will influence it with their vision
– PMs, VPs, CxOs who will manage it and fund it
Basic example questions
– What are your current pain points?
– Without a design system how many hours does it take you to X?
– What would be solved if you had a design system?
– How often do you have to refer to something you did earlier?
– What are the aspects of a design system that help you with your work?
– How should these aspects be delivered to you?
3. Gather data
The research team has gathered a lot of background information. Also they have gained sufficient knowledge of the inner workings of the teams that will use the design system, as well as the stakeholders. They gained understanding on what goes on on their minds, what their pain points are, and how they would want to ideally work with a design system in place.
All that information has been archived and now they have to make sure that everything is gathered together for closer analysis. Everything is on the table. And everything is a valid point at this moment. There is no worry about quality of information; just make sure that every stone is turned. The data is now in a “raw” format, and it does not matter.
Although this step might feel more logistical and operational, rather than creative, it is much needed in a design research process.
4. Analyse data
After gathering the data, it is time to make sure that all information the team has gathered is organized in a way that makes sense.
Data synthesis is the next step and as important as the rest of the steps. It takes the ability to read through different kinds of information bits, understand them, find the patterns, and connect the dots.
Here the research team starts creating clusters of information, and seeing areas of focus emerging. Based on the research and knowledge gained, they can then define the prioritization of tasks and development. Out of all those, they should now have clear actions for the future of the new product — the design system. It is good to remember that this process (research, design, and the building of the design system), is not a one time process. Going back to Nathan Curtis’ comment at the start of the article; “a design system is a living, funded product”.
5. Learn from the findings
The research team has to bring all they have learned together in the end, and present the findings with the ecosystem. Gather feedback, and create a transparent dialogue for what happened, and how to move forward. A design system is a great opportunity for organizational design. And of course it is important to create ways of working that will ensure a healthy environment and a stable basis of product/service building.
The actions that define the next steps have to be done in a similar fashion. A team does not want to release a design system in 2 years, where most of the products would already have changed. They do not want to release a design system in a company setting where information is not flowing between teams. If they do not understand their needs, their design system may quickly become obsolete. Furthermore, they do not want to build a design system where there are no processes in place AND they cannot scale the operations of the work on the system as fast as the rest of the products.
Conclusion
Obviously this is the part where I tell you the right answer is; Your mileage may vary. Treat this guide not as a step-by-step process, but as a reference. Like with any design tool or methodology, it all depends on the dynamics of your teams, the intricate relationships and politics of your company and the willingness of your teams towards change versus inertia. If you do your research well, and understand your users and their needs, you are less likely to fail at building a good system. A systematic approach to design research is never done, but ever involving. Doing it once will not guarantee you success. Iteration is a keyword you should keep at the core of the process. Luckily there are several examples in the field to draw inspiration from. At Clarity in 2016, Donna Chan and Isaac Hayes gave an insightful talk on how to build empowering style guides with practical research.
Invision Studio is just around the corner. I got the early access, but I am supposed to keep it hush-hush for now. I have seen what it can do, and what it could potentially also be in the future.
Last week I read an article on Fast Company, about Figma and their vision of being the platform at the intersection of design and engineering. I admit I have only tried that tool on a surface level. A lot of designers seem to dig it, therefore I presume it is a valid tool to get stuff done.
Being a user of Sketch, myself, I have never been happier with a design tool in my professional career. I made the switch back in 2014 from Illustrator, and never looked back. While still using Adobe products, it never felt that something, even XD would make me feel the need to switch.
And should it?
Designers care about their efficiency, creativity, communication, compensation (tangible and non tangible), learning, and professional development. I guess, what I am trying to say is that designers do not care about specific tools, but only about their investment in those tools.
For the community to move past beyond the everlasting discussions of “design tool wars”, we need to setup some principles so that the future of product design is not governed and moderated by the limitations of the tools we use, but only by the level of progress we are willing to make.
A true open platform for designers
Design work should not be dependent on any design tool. For an open structure like that to ever exist, we have to borrow notions from the engineering world, again. Choosing your own text editor should be a matter of personal taste as long as we can work together.
Imagine a design team that is working on a product on multiple tools creating 1 deliverable. Impossible?
Universal design format
An open format would be a great start in that direction. The team has files for every page they are building plus their libraries. A file while working on the home page of an app could have a home.dsgn filename attached to it and the library of elements is coexisting in the same folder under styleguide.dlib
Yes I just made those extensions up but you get the idea.
We all edit the same files in the team. I am super fast with Sketch. Lana really enjoys the web version of Figma. And Jason is “the windows guy” so he uses XD (seriously Jason…?).
Version control The open format opens up the field for tools like Abstract. I had the pleasure to meet Josh (CEO of Abstract) at DSCONF — the design systems conference I organise in Helsinki, Finland. Josh is a bright guy and he shared his vision on version control while showcasing the bleak truths of teams and what they go through — STILL — nowadays when they have to work on the same design files.
The open format would let tools like Abstract acting not only as the single source of truth, but a further step into true design collaboration. A GitHub, or a way to integrate with Github (or Deshub™ — lol cheeky, I know) for design teams, combined with version control and a complete breakdown of everyone’s changes, additions, and documentation of their actions.
On getting stuff done
It all comes down to that. For a long time we stood and watched a new design tool emerging every week that promised to be the next true tool for the design community. The truth is, it doesn’t have to be like that, and obviously it is not a race.
What we do care about, at the end of the day, is our own efficient way of creating value to the products and services we are working for. Give us the freedom to be truly free to use our creativity.
So let’s drive this as a community towards an open platform for designers?
Everyone is talking about it. At the same time whenever everyone is talking about it, there is a lot of buzz and hype around it. That is great. But it should not take us away from the prime reason of Design Systems. They are here to serve as the single source of truth for delightful and functional products and services.
At DSCONF, we felt that we ought to open up the conversation. In the local scene, of course, but on a global scale as well. We have keynotes, talks, case studies, workshops and networking. All of these formats of communication are catering people who are advocating design systems, people who are building them, people who are thinking about creating one, and people who want to know the value of design systems before they put their money on it.
Design Systems; a genuine way to bind disciplines together
The message is clear: It is hard to create a good user experience, and moreover, a cohesive good user experience, that is continuous and scalable. A lot of things happen in the area of Design Systems and in cross disciplinary levels in teams.
In engineering, React excels through a really strong support of a massive community, plugins and solutions. At the same time resources as Storybook, have created grounds for teams to dip their hands in creating their first living style guides. Consequently, the immense race of Vue (now the most growing library on Github) to the top, has bred a great amount of solutions to the table, bringing a whole new air to the Design Systems community.
In design, plugins in sketch spew out of developer repositories to help designers keep up in a fast paced environment. Sketch itself has now shared libraries, a major step towards up to date style guides in design assets. Products like Figma bringing real time collaboration to the front, while tools like Abstract bring an easily integrated solution to design versioning control. Invision Studio is one of the most anticipated tools for 2018 and there is literally a myriad of design tools out there.
In business, management of teams implementing Design Systems in their products have seen the results in KPIs, and improving in customer experience.
If you did not guess it already, this is heralding a new era of collaboration between disciplines.
Proven results
Somewhere in 2011, investor Marc Andreessen penned his famous essay on the WSJ, known as “Software is eating the world”. Today there is no sign of that trend slowing down at any given point, therefore we understand that the need for Design Systems to serve as the single source of truth is becoming excruciatingly critical.
In their Enterprise UX Industry Report, UXPin concludes that 69% of enterprises, companies such as Saleforce, IBM, Airbnb and Atlassian, either have or are currently working on a design system. At the same time 59% of the companies think that their biggest challenge is improving consistency!
Software is built by a large amount of people with different backgrounds. Often, the amount of people involved in a development of a product can explode as a product matures and grows. There are in house people involved, consultants, sometimes freelancers…
Design Systems are there to serve by establishing a clear path to consistency. An inconsistent product leads to user frustration, an unclear design process, a slow development time and ultimately more costs. By nature, good design should provide clarity in products, and with that, Design Systems establish a level of familiarity and safety to the user.
A (not just only) digital transformation
The recent years, depending on how you see it, have been the golden era of design and development solutions, or the era of great confusion. Personally I tend to think that it is not the products that make the professionals, but the opposite. So, I have been enjoying the development of those solutions and welcoming the challenges that they bring along the way. Faster than ever you can develop a product, test it with crowds, develop it, release it and ship it to millions.
Tools
With design tools nowadays a designer spends just $99/year to be able to design a full product. With recent development frameworks you build a scalable service and you can deploy it in cloud services with minimum costs until you hit critical mass. You can reach millions across the globe with user testing services, and you can market to millions with social media. The world has not been more agile but also cluttered!
People
Designers, developers and marketers are merging together in teams. At the same time those professions are not anymore strict to their respected skillsets. Designers learn to code, more than ever. Developers are able to prototype and create user experiences. Marketers can fuse design and developer skills to create compelling growth hacking techniques while at the same time gaining insight how to do that without compromising user experience.
Organization
In behemoth companies like IBM, we have seen a massive transformation in Design Thinking mindset. At the same time, enterprises like Intuit has done incredible work, exhaustive studies, documentation and building on Harmony, their Design System.
So where does that lead us? We need a common ground to be able to come together, hear stories, share experiences, get contacts and build together a better digital footprint for humans.
At the crossroads of expertise
DSCONF presents a unique opportunity. We combine two different vantage points when it comes to Design Systems. Speakers like Nathan, Jina, Hayley and Karri have incredible experiences and stories to share, bringing a worldwide view to the motivated and eager to learn northern tech & design scene. At the same time our partner companies talk about what has been done locally, and sharing their own experiences and journeys to the global market, to showcase their way of doing things.
Do not let the technical terms scare you. In the end we all try to solve real problems. The best tool to equip with you whenever you decide to come to DSCONF, is an open but critical mind.
—
DSCONF is an event for digital product designers, builders, business owners and organizations who want to learn how to build design systems and why they are needed in the future. We are at a crossroads whereby making the right decisions, you will gain a significant business advantage and ensure the best possible user experience for your digital products and services.
There are a lot of articles out there that will tell you how to become the best designer in the world! Some of them are probably pretty good.
However this one… Well, this one is mine.
Starting off, I will give you a bit of TL;DR. You will not learn here today the holy grail of skills of a perfect designer. If you are disappointed, I just saved you 4 minutes of your time, give or take. What you will learn today, is another designer’s opinion on how to make something meaningful out of your craft. And maybe you could follow a similar path.
Learn
This must seem a bit of a cliche advice but if you are not learning you are doing it wrong. Seriously, change is light-speed in the field of design. Just see any article about User Experience in 2013–2016 and now.
Some ways to learn:
– Books (obviously)
– Articles (there are amazing publications on Medium and not only)
– Workshops (attending, working, practicing, networking)
– Hackathons (challenging your skills in lean multidisciplinary teams)
– Collaborate (Volunteer with fellow designers and engineers)
– Side projects (step out of your comfort zone and do a project that can challenge you, like mentioned also above)
Accept criticism If you do not accept the fact that you can do mistakes then you are not a good designer. If you do not respond well to criticism, how are you going to improve? I believe that by challenging each other to do stellar work, we are creating an environment that people can thrive. Plus it also links to the first point – learning.
A person who never made a mistake never tried anything new
— Albert Einstein
Bonus; Fail!
Fail, fail fast, fail spectacularly, then sleep it off and do it all over again. Most of us stress over the fact that our position is getting diminished if we fail. However, failing is a learning way (not mentioned above because it deserved its own space). Failing is one true nature of human beings and we must embrace it as a driver to better ourselves.
Give back to the community
I have established an acceptable network and I have some experience that allows me to be able to share one thing or two. I am convinced that one of the best forms of incentive for things you do, is people’s gratitude for teaching them stuff. And for this reason I want to continue doing it as much as possible.
As designers we have a responsibility when advocating for the user, to keep one fundamental principle up high: Being human. And we can do that by building ethical products, work in ways that we leverage our teams, and delight our customers. On top of that, giving back to young talents and people who want to be part of our craft. I like to think that design is the most inclusive craft. Is it?
Always ask the ‘why’
There are a lot of times that you will be presented with a decision that you will not agree upon, based on your experience. Challenge that. I am not telling you to be a d*ck about it… Just, defend your thesis. If you have a valid argument, present it. If the other person is wrong, lead her/him to that conclusion.
‘Why’ is probably one the most important tools in your box. Asking the ‘why’ to your methods, to your teams, to your products, to your own users, trying to understand and make sense of the world. How else are we able to add qualitative data to our decisions?
Be code literate There is a lot of discussion and debate around whether designers should learn how to code, or not. This is a discussion that I personally believe wastes everyone’s time. It is solely up to you, as a person to build your career to your own needs and wants.
However, based on my own experience, I can give one small advice to keep in the back of your head. Knowing how to code (HTML, CSS, and a tiny bit of JavaScript), has helped me a lot as a designer. Working as a product designer in multidisciplinary teams, 95% of my time I do not have to code a single line. But by understanding those languages, their capabilities and limitations, has helped me to create viable products and services with my teams.
Be data informed This last piece of advice ties nicely with the one above. Understanding data. You might have noticed that I didn’t use the word combo data-driven. Yes, this is correct, and there is a simple reason; I prefer being data informed, because understanding users is not just retention and activation numbers. Understanding users, require a suit of cross-disciplinary professions, that product teams should strike to achieve.
Document (2018 edition bonus)
This just in, a bonus advice for 2018. Document. Document everything you do. This last piece of advice (for now), is so important, but so normal to me that I almost forgot to mention. Every project you do, every feature you ship, every design decision that has lead to a bad or good result, have a lot of learnings, feedback, measurements (data huh!), technologies used, and ways of working with people (whether they are your peers or your users). So I hope you see what I did there… Documenting can contain all the points mentioned in this article. And by having an archive where you can recall and do a retro at any time, can help you learn.
