And what we need instead.
Problems, Fixes, and Solutions
In his book, The Slight Edge, author and serial entrepreneur, Jeff Olson, tells a story of how information and knowledge alone are not enough to solve the problems we face. He gives an example of an alcoholic in the street, who struggles with his addiction.
Olson suggests that with all the technology and medical advancement available to us in the past 20–30 years, we could give the guy a simple flash drive with all the information (like 12 Step Program video courses, books, lectures, and contacts of support groups) needed to cut his addiction for good, yet this quick fix method doesn’t work.
Instead, the number of people addicted to various substances (or almost anything dopamine-generating) keeps growing each year. He concludes that reaching more people and giving them access to more productive information alone is not solving the problem, because the problem exists on a fundamentally different level. As well as the solution to the problem.
How Incremental Design Nurtures Limiting Habits
Coming back to the design world, over the past few months, we saw a boom of new design platforms. Tools like Figma, Avocade, Mervel, Fluid for Sketch, Adobe Project Comet, keep popping up here and there, and most of them are actually delightful to use.
There are a few trends that led to such a variety of tools:
- Increased demand and ease of entrance to the profession for digital designers;
- Unification of platforms, their interaction, and visual languages (e.g. iOS becoming less graphically complex and more structured, and Google introducing unified Material Design guidelines);
- Increased specialization (designers are more likely to be expected to deliver good enough iOS-only design, not outstanding digital design in general).
Which is totally understandable. As the industry develops, we see more fragmentation and specialization, while stable oligopoly of key players, like Google and Apple, make it easier to create, distribute, and learn specific applied educational content, design components, and guidelines.
What strikes me as a practicing UX designer, however, is the focus of these new tools for designers. Most of the new solutions tend to focus on:
- Simplification of existing design process;
- Enhancing mock up interactivity (e.g. with animations or gesture/device responsiveness);
- Enabling distributed / remote reviewing process;
- Making it easier to hand things over to developers.
Those are amazing things by themselves, but they fundamentally focus on incremental improvement of existing workflows in design.
In a way, these solutions are there to say:
‘You do things the way you do, and we are going to let you do them exactly the same way, but in less time and with more remote people involved. As a cherry on the cake, we’ll let you throw some interactive animations in the mix’.
The problem is, some of these existing design workflows are already limiting, while the definition of designer is rapidly changing.
Product Hunt’s homepage is a good showcase of how well-designed products are created every day by developers alone. Indeed, why do you need designers, when you have structured sets of design components, unified under well-documented design languages of Google and Apple? You don’t even need to open Sketch or Photoshop, nor any other design tool.
The design platforms that we get often are just quick fixes. We seem to forget about the elephant in the room, that is, asking a very important question: How is the way we think about design changing?
Design + Change = ?
In his great article, Dribbblisation of Design,
of Intercom suggests that many designers tend to play too much with the very basic level of visualization of ideas with subsequent interlinking of those visualizations in a set of static (or semi-animated) screens. He continues by saying:
If product design is about solving problems for people within the constraints of a specific business, then it simply feels that many people calling themselves product/UX designers are actually practicing digital art. They are Artists. They are Stylists. Executing beautiful looking things, certainly an important skill, but not practising product design. […] Designers certainly need to define the problem and solution not in pixels, but in terms of describing what happens between components in a system.
To take is idea further, it’s important to entertain one crucial assumption. Here we go:
Craftsmanship alone, which has served us designers so far, is not going to make us successful anymore.
It’s not only about making things prettier using your craft, and it’s not even about solving problems using your craft and your thinking. It is more and more about continuous envisioning of experiences that are not yet there. Another way to put it: Design becomes a structured approach to iteratively bring, test, and enhance multiple future visions within the current setup.
What Do We Need?
To be successful at envisioning intended experiences, as designers, we should keep the following things in mind:
1. We should be familiar, comfortable, and increasingly fluent with the whole process, not just a single part of it.
The growing community of makers is a good example of how the notion of craftsmen changes. Professionals coming from various backgrounds like software engineering, design, and marketing are united under common idea of shipping products that people need and like as soon as possible, learning from feedback, and enhancing things on the go.
It sounds counterintuitive at first, but in many areas, it doesn’t even matter how your design looks until you release it, and start learning. As
, Product Design Director at Facebook, puts it: “Design thinking’ is becoming just product thinking.”
2. We should employ different layers of thinking.
Remember Edward de Bono’s method of six thinking hats? To solve complex creative problems, de Bono suggested, you put on one imaginary hat at a time, representing a different modality of thinking.
In a similar manner, as designers, we should be able to put on our user experience, visual, technical, business and growth thinking hats to make products that deliver value.
Here is an example that happens quite often: Adesigner proposes a solution to a developer, who says that it somehow feels strange within the context of the framework used, at which point the designer realizes that she didn’t take some of the framework features and conditions into account.
The problem is we don’t design any tools for gut feeling research and empathic discovery, but we design tools for increasing productivity and maintaining conventions, which brings us to the next point.
3. We should treat the tools as derivatives of envisioned product experiences.
Only when we have a shaped hypothesis about the experience in mind, should we proceed to choose the right tools. Not the other way around. Going with Sketch or Framer.JS or
or Principle or plain HTML/CSS or WordPress or Meteor or
or
or any other tool should be a decision based on the needs we have, taking into account our current product hypothesis, constraints, and the effect needed to move things forward.
We should be flexible to drop unnecessary tools and switch to something else, be it another app, web platform, or hardware prototyping kit, or marketing lead generation engine. The notion of design tools changes with the notion of design.
4. We should be able to begin, proceed and finish with the end in mind, continuously iterating as the conditions change.
What we define as ‘the end in mind’ is more important at each iteration than the tools we currently use. In his book, Zen and The Art of Motorcycle Maintenance, Robert Pirsig defines “Quality,” or “Value,” as something available through perceptual experience only, which can’t be fully understood intellectually in the moment. In a similar fashion, if we define quality of envisioned experiences as ‘the end,’ we might channel our design thinking towards creating minimal conditions that allow this experience to happen, and be observed, letting our vision evolve.
5. We should learn to generate insights from data.
As experiments become more common tool for decision making support, we should understand how to interpret data and use it to design better products and experiences.
In the most basic model of human-centered design, we use methods for empathic insight generation before and while we solve problems for users. As quantitative data becomes widely available with every new prototype, we should learn how to use all the information we know to make better design decisions. Relying on analysts, product managers or developers to do so, automatically means we rely more on somebody’s interpretation, and have a harder time applying it to the design process.
In his book, How to Measure Anything, Douglas Hubbard talks about how measurements, asking right questions and analyzing even tiny amounts of data can lead to more informed and dramatically better decisions. A few insights that Hubbard says applies to almost anything:
- Your problem is not as unique as you think.
- You have more data than you think.
- You need less data than you think.
- An adequate amount of new data is more accessible than you think.
The problem is, since we don’t know how to measure and interpret data, we rarely assume the data we have is valuable. Here is an example that illustrates this point. As a founder, thinking about starting your own business, you might try to calculate more or less exact costs and revenues of your company, which is problematic at the early stage. However, just mere analysis, revealing if you’d be profitable (Yes/No), might be enough to make a decision.
6. We should be fine with change, and therefore, create the fruitful context of work as much as we define the content of work.
Throughout technological revolutions, most of the dramatic change for mankind was introduced via invention of hardware (e.g. plough, steam engine, transistors). However, in the last couple of decades, most innovation was driven either by combination of hardware and software or by software alone. Software evolves much quicker than hardware, mostly because of its distributed nature. And most digital product design evolves just as fast.
We still use more or less the same plastic, metal, and glass boxes with pretty much the same features as we did in 2007, when the iPhone was introduced, yet the diversity of platforms, visual languages, and possible interactions increased dramatically.
In these conditions, we can either specialize deeper in fewer things, or know a bit about everything. Or we can choose to focus not only on designing applied software, but on designing applied human interactions.
In his bestselling management novel, The Goal, Eliyahu Goldratt shows how a protagonist, faced with troubled manufacturing operation, one by one identifies and eliminates critical bottlenecks, which allows him to dramatically influence the throughput of the whole factory.
In the design process, way too many bottlenecks are related to the process and to the role of human interactions in it. There is still a lot to learn about the methods of effective collaborative design, working in teams full of highly creative people, or giving and receiving effective feedback.
In this sense, the best use of time is not about chopping the trees with the newest axes available, but about spending time sharpening them with fellow axemen, sharing tips, tricks, and nurturing relationships. This way when change happens, you are prepared for collective action, informed about options and ready to learn any new technology to be up and running in no time.
So What about Design Tools?
Following all the changes that designers face, tools that we use will change as well.
1. Design tools that maintain quality of connection between designers, developers, and other makers will be on the rise.
They are not the instruments for micro-feedback and feature development, but tools for connection, visual thinking, and co-creation.
2. The tools designers use will be close to the tools that developers and marketers use.
There is little difference between the maker who came from a design background, and the maker who came from a software engineering background. It is all about embarrassing code, persistence, and luck.
Tools like FramerJS and Fuse set an interesting path: They try to simplify development syntax and vocabulary to translate it into interactions. If you come from the other side, you might notice that development platforms, like Meteor, quickly become design tools themselves. They are making frontend and backend development and dependency management ridiculously easy, even for non-professional developers.
3. We will need to learn to code anyway.
It just makes sense. Kids in schools have coding as a part of their curriculum. We live on software, developed for us by somebody, and we miss a lot if we don’t know how it works. We are most likely involved in creating software ourselves. So it makes total sense to learn coding to enhance our design process, which brings us to the next point.
4. Tools for development will become more accessible.
Designers and prototypers long complained fundamental means of development didn’t change for decades. Things recently started to move quicker: many prominent accelerators are looking for startups that aim at simplifying the coding process.
Y Combinator’s Request For Startups page, for example, states:
‘We believe it’s especially important to build products that make software development accessible to the widest part of our society. In fact, we’re especially interested in new ways to program. There are probably much better ways for people to program, and figuring one out would have a huge impact. The frameworks are better, the languages a bit more clever, but mostly we’re doing the same things. One way to think about this is: what comes after programming languages?’
So it makes sense to look for frameworks that allow us to prototype and co-create with developers to make the distance from hypothesis to learnings shorter.
5. We will be more involved in creating the right context to make it easy to create content.
Companies like IDEO, the leader in the design consulting field, know the value of establishing right culture to reproduce outstanding results. Once you create an open, values-driven culture, in which everybody is free to experiment, build, and work collaboratively without fear of failure, you automatically create the conditions that foster creative growth. The nature of business may change from industrial design to service design to digital design to organizational design, but having a solid cultural foundation it’s always easy to pick up new skills and evolve.
***
There are clear signs that fixes, popping up here and there, will soon start converging into more meaningful collaborative solutions. These solutions will make visual design and coding secondary to the ability to quickly envision and evolve possible futures, which is what designers will be hired for.
Leave a Comment