Building successful design systems with well integrated research

A research guide when starting a design system.

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.

Creating a true open platform for designers

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?

Why are we building a design systems conference?

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.

Becoming a superstar level designer

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.

The “Everybody is a designer” kind of article

Every once in a while, the conversation about Everyone being a designer is bound to happen. This conversation reboots in uncertain patterns of time, but it sure frequents the lively Slacks, Twitter feeds, Medium articles… You name it. Then the crusaders of both sides march with their spears to defend or burn Rome once again.

Yes this is an article on this subject.
No it is not an article supporting or bashing the motto “Everybody is a designer”.

Designers in 2017
As part of startups, people like me, designers get to influence products, and those products — in principle, and in practice fortunately, influence the lives of thousands and/or millions of users. The processes put in force are not limited to drawing boxes, although man do we love boxes (and thinking outside of them, yeah).

Designers become oftentimes tech savvy. They do feel the need to know code & code more. They do not do that to steal a developer’s job. Unless they want a career change. They do it to become more informed. And designers have to be more informed.

Designers have to be more code-friendly. They have to understand limitations, capabilities and opportunities. Inverting this statement the opposite holds also truth. Engineers should be design-informed. They should understand and translate the value of a specific design they are asked to implement. And they should realize the reasons why a user prefers red over orange.

– In the same respect, a CFO should understand the value of design.
– A CEO should know the reason why design deserves a seat at the C table.

A practical example
I like code. I learn how to code. I am confident with my HTML and CSS skills and I want to master better the elusive (for a visual person like me) JavaScript. I do not want to start building a project as an engineer. I want to use my skills to better communicate my designs.

If I can pick up a pen and a paper, and fiddle around ideas and come up with a feature, I have done already a good job. If I can design a pixel-perfect mockup out of that I am already a lot better at this. If I can understand the users opinion over that design, I have validated some value. And if I can prototype that design, with code and create an almost real-life example of that feature, I have gained loads of experience, I have saved tons of money to my company, and I have saved valuable time for an engineer.

Do I wanna call myself an engineer? No. Should I? It is not relevant.

Yes, everyone is a designer
And if an engineer, CEO, CMO or [Put a fancy title here] wants to do my job as a professional product designer they have to be prepared to:
– Lower their salary level (sic)
– Research
– Validate a feature
– Do design sprints
– Conduct Usability Testing
– Perform heuristic evaluations
– Do some app-screens mapping
– UI audits for cross-platform interfaces
– Identifying and meeting real users
– Create user personas
– User journeys
– User flows
– Learn how to use tools like Sketch, Invision, Principle, UXPin, etc
– Prototype (paper, sketch, UXPin, Invision w/e)
– Design pixel perfect mockups (Use your weapon of choice here as well)
– and then some

Now, if people are happy to pick up and learn to perform these skills of the trade well, I am happy to include them in my team. They will become a valuable resource for me, as we would both become for efficient.

Top 2017 trends influenced by design

2016 was the year where User Experience, and more generally Design, took a big fat seat at the C table. Yeah, of course it was not the first time this has happened ever, however this year everyone went crazy talking about design. Design thinking, user experience, startups, company culture, users, customer customer customer, CX,UX IxD, …you name it.

There is a good reason for that. The success of strong design-led-culture startups and design leadership left even the more stubborn and set back minds with a big awe over high performances, amazing key metrics and stunning products people WANT to talk about. So where does this really lead us, now stepping into 2017?

I would say, that this must be one of the most exciting eras in our times to be a designer. So lets try to identify some exciting trends that design could or will help shape up in 2017.

For the TL;DR version here’s a list of things that designers will have an impact on 2017:
– Virtual Reality/Mixed Reality/Augmented Reality
– Artificial Intelligence
– The real Web Design 2.0
– Connected world

Virtual Reality/Mixed Reality/Augmented Reality

The world is your canvas
There are many exciting ways that Virtual & Mixed Reality will influence the ways we experience things. Claudio Guglieri, a product designer formed a hypothesis where he did a study of how such technologies will influence our surrounding in public but also private spaces.

Mixed reality will ease the cognitive load associated to informational and promotional signs in public and private spaces.


– Claudio Guglieri

In this study traditional ways of communication will be the first ones to be disrupted, followed by the public and private spaces. But where would designers contribute?

Designers would have to rethink how the users perceive information interacting with their real-world surroundings. What the user wants to see on a personal level, choosing the information, when and where it should be distributed to her. Also how this UI will be unobtrusive with the real world, providing at the same time a seamless experience.

A fresh premise here is that traditional UI patterns will indeed break and fall apart, therefore we would also need new studies on the subject of UI Design, and Interaction Design without a grid.

A digital playground
If the previous topic left you with a dystopian fear let’s move along to a more fun subject. In 2017 we will see more immersive experiences, coming up from various fields. Edtech, leisure, travelling experiences, entertainment, gaming just to mention a few.

Designers need to identify the best graphic engines they are going to be creating with, and how those designs, or media will be interacting with the user.

Is there a limit to where the user can go? What kind of options and levels of customization can become available to people when using apps like Tilt Brush? How immersive can the experience of games like Eve Valkyrie can become? Could I even walk on another planet? I sure want to!

Artificial Intelligence

Intelligence; not strictly human trait
Machines become more intelligent, and now they also start learning like humans do. At the same time we have to give them input so people can interact with them. From personal assistants and chatbots, to hands-free interaction with an app, conversational UI has become a hot topic in the design watercooler and some designers already work on such solutions.

It is pretty clear that as designers we have to think of a quite many unused solutions and patterns when it comes to such UIs. It is not only what color those chat bubbles are going to be, but also, are there going to be bubbles at all? How do you display something more than a simple text message? What about a link? Or even an application? Tomaž Štolfa explains the future of CUI in a thorough article and talks about such ideas like Rich Messages that each of them becomes an atomic application.

Waiting times
Furthermore in CUI and chatbots, Interaction Design plays a huge role. More specifically the Perceived Performance is vital. If you have not heard this term before, it is rather simple. How fast the user thinks the website or app is interacting with him.

Jakob Nielsen in Usability Engineering, identifies three main response time limits:
0.1 seconds — Actions that take 100ms or fewer are instantaneous to the user. This is a golden standard aim for any interaction.
1 second — Actions that take 1 second to finish are generally OK, but the user can identify that there is some sort of pause. If all actions would take 1 second to complete, your website may feel a bit sluggish.
10 seconds — An action that takes 10 seconds or more to complete, there some kind of attention grabbing has to happen for that time spent on ‘waiting’. Depending on the action they are completing, users might navigate elsewhere, or simply leave your site.

Eli, a FrontEnd Developer has put a nice slideshow on the main aspects of Perceived Performance. As he puts it, it’s the only kind of performance that really matters. Take a look on the link below and use the left-right keys to navigate through.

The real Web 2.0

Remember when around 2012 or so, we were talking about web 2.0? Yeah, me neither. The thing is that nothing really felt as groundbreaking. Sure redesigns has revamped services that we use everyday, and sure we have come a long way, but that is only a natural progression.

Barebone apps
In the recent years and I would dare to say more in 2016, we saw apps becoming less complex more and more (see what I did there), and reducing their UI to the very basics. Icons to interact with, lines and neutral backgrounds.

You might feel this could be a bad thing, but for such apps there is usually a reason for that. The content is indeed king, and these apps empower such content to be more prominent. A handful of examples are apps like Instagram, AirBnB, iTunes, Youtube, and our beloved Medium.

Yep, Michael Horton from Swarm has coined a term for it, because why not. We need a name for something that will likely be discussed in 2017. And that term is Complexion Reduction.

The art of storytelling
In the same direction web designers start reimagining how websites can provide richer experiences. Storytelling, a really sexy subject around design and marketing, is indeed being pushed from articles, movies and ads to even websites. Storytelling, if done right, can convert users better than any crazy growth hack you can imagine. Maybe… because it is more sincere?

In this sense websites also become more fluid. Moving away from traditional grid systems. Designers think outside of the box, and many times, design also outside of the box. Should a website move only from top to bottom? Or just have pages?

Connected World

Connected cities
Kinda everything becomes more intelligent around us and so our cities need to become more intelligent (and oh god indeed do they need to). If you think that this is a far fetched reality, you bet someone is already thinking about it anyway. And someone else is already doing it.

For example, Embers is providing open interfaces and SDKs for startups to create services for cities. The data they provide are around traffic, parking, routing, & environment. We need new studies, we need to understand user needs in connecting the physical world, how does traffic for example, become more intelligent, safe and maybe fun as well.

Connected Home
On the subject of more fluid UIs or no UIs at all, conversational UIs and so on, we now move to a more human oriented interaction; voice. Devices like Alexa are entering homes and come with no UI at all, just voice activated commands.

At the same note, even your coffee maker is becoming smart and brews you some great coffee in the morning. Sure, I agree, it is not needed to many, but there those problems (or luxuries?) are being tackled by companies and startups.

Designers are needed to understand how to empathetically bring those devices close to users, so that they are not just machines but extentions of what we actually call home.

Connected Cars
By 2017 there is a great increase of cars that come with internet connectivity, and it is expected that the number is going to be around 75% of total cars in 2020.

Generally a car has a great lot of data. It is just… not so shared. Most of that data is actually not even accessible by the consumer. However as we move towards more connected cars, much of that data will start being unlocked for the favor of the car owner. Regulations in regions like Europe push towards this direction as well.

We already see cars being shipped with touch screens, apps and autopilots! So designers need to design those experiences around the safety and delight of the person seated in the car. And with companies like Tesla we see how far beyond what we have now, the car industry could be.

Epilogue

We live in an ever-connected world. This is a scary but also exciting era to live in. And it is exciting if we get to shape just a tiny bit of that era as designers. Using trends, studies, conversation and a lot of empathy, we can influence that the products around us are made really for everyone to use. So where do we go from here?

Now, it is 2017. 3 resolutions for designers, plain and simple.Let’s start designing experiences.

For and with people.

Let’s start calling our users: people (maybe Human Experience?)

“Only two industries refer to their customers as ‘users’: computer design and drug dealing.”

-Edward Tufte