1

Wireframes are useless

 3 years ago
source link: https://uxdesign.cc/wireframes-are-useless-14ac7d22c961
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Wireframes are useless. Why we stopped using them and how it…

We’ve never been big fans of wireframes. So the goodbye wasn’t that difficult. When our design studio was founded four years ago, we got rid of them all together and never looked back. But then with one little Instagram post, we found ourselves having to defend the decision. It was a conversation with our friend Fabrice Poehlman. He quickly mentioned how he found wireframes irrelevant for designers.

We responded that we agreed with Fabrice. Wireframes no longer play a role in our daily work either. But then came a flood of comments. The audience began to argue things like, “With wireframes, I can better present a concept,” “I can quickly test ideas for their usability,” and “They are indispensable for the cooperation of developers and designers!”

So we took a step back and thought about it. We then realized that within the four years that we’ve been operating without wireframes:

So, we thought the best way to approach this matter would be to breakdown the most common arguments for using wireframes and explain why we still believe we’re better off without them.

Disclaimer: What are we talking about when we talk about wireframes?

Before we dive into the good stuff, let’s define the term wireframe. In web design, wireframes are used to visually represent the structure and functions of a website. Usually abstracted in grayscale and with placeholder content. The spectrum is large, but generally speaking, there are two grades of wireframes: The first are sketches created with pen and paper or whiteboard and marker, these are low-fidelity wireframes. The second are concepts that are created with the help of apps, these are high-fidelity, digital wireframes. Unlike a sketch, the solution becomes more tangible and the level of detail is higher. Conventional interaction patterns illustrate the functionality and provide guidance for further product development.

Sketches of one of our projects.
Sketches of one of our projects.
When we talk about wireframes, we are not talking about sketches.

When we say that we don’t use wireframes, we’re talking about high-fidelity wireframes. The kind that are created using software and are meant to be a blueprint or guide for the user interface. Low-fidelity wireframes on the other hand, are needed by all of us to express our thoughts and develop ideas together with our teams. We tend to call them sketches or scribbles. Therefore, for simplicity’s sake, we’re talking about wireframes as a deliverable — something that you’d send to customers. Those are the ones we can do without.

Argument 1: Wireframes allow us to decide on strategic and content-related questions

Wireframes are often used to make conceptual decisions about the structure of the webpage. However, even before each design draft we have to clarify a few fundamental questions such as: what goal do we want to achieve with the page we design and how can we achieve this goal? With the answers to these questions we define the strategic direction and set the cornerstones for our design activities. We don’t build the strategy simultaneously with the visual design. Creating wireframes can really only help us to visualize the thesis we have developed.

Before deciding on what the page will look like, we have to establish a common understanding with all stakeholders around the desired goal. We create this understanding with our “Core Extend Jump” model (linked below). This model enables us to form strategic goals and decide how we’re going to achieve them — even without design know-how. Our frame of reference helps to cut the big questions into manageable slices. This allows us to make decisions at the strategic level that help us to answer questions about design, content and function afterwards. This way, we ensure that the design follows these decisions and properly expresses them.

Strategy informs visuals, they can’t be mastered at the same time. Wireframes simply try to do too much, too fast. When you try to master everything….

Argument 2: Wireframes allow us to test the product thesis early on

Wireframes are often used to test initial hypothesis in the form of user or usability tests at an early stage of development. The goal is to find the evidence as soon as possible and the hope is that wireframes will provide insights into the product experience and help to determine the pros and cons of a solution.

The idea isn’t a bad one, but unfortunately users aren’t always able to take information from a wireframe and understand how it will translate into a digital experience. Wireframes are simply too far away from what users expect from digital applications in 2020. In a test with a wireframe, users don’t experience the readability, the colours or the ergonomics and therefore nowhere near the entire usability of the product.

Use of a product in front of the airport.
Use of a product in front of the airport.

What we ultimately strive for in a test is immersion. We want to get as close as possible to the real context of use. In an ideal world, we are able to silently observe the reactions, gestures, interactions and thoughts of the test user. High-fidelity wireframes just can’t provide that for us. In our experience, it doesn’t require a fully developed prototype that already represents the brand and includes all functionalities. A simple click-dummy is sufficient. The determining factor is that the test product runs on the appropriate device, is equipped with real content and visually resembles the majority of the products that the target group deals with on a daily basis.

The sooner we create an experience that comes close to an interaction with a real product, the sooner we can obtain reliable results. Wireframes aren’t high enough fidelity to get the answers we need.

Argument 3: Wireframes accelerate the process

Wireframes are often used to put product ideas on paper quickly. The claim is that the arrangement of elements without visual or functional characteristics is a big time saver!

The argument that wireframes are a time-saver was absolutely understandable… 20 years ago. At the turn of the millennium, designers around the world created digital layouts using Adobe Photoshop. It took a lot of time to develop a design. It wasn’t until 2010, with the increasing success of Sketch, that layout tools found their way into digital product development. Today we work with Sketch, Figma, Adobe XD, Invision Studio and many more. And meanwhile, component libraries such as Google’s Material Design are integrated directly into the apps. With tools such as Unsplash, icon libraries and a variety of illustration sets, suitable content can be generated quickly.

A look over the shoulder of our team member while designing.
A look over the shoulder of our team member while designing.

Now, if we pulled a stopwatch out of our pockets, the wireframe may still win the race today. But we have to ask ourselves how valid and sustainable these results actually are. As designers, it is our job to design an experience that creates value for the user. The faster we can prove this, the better. That’s why we always invest our time in creating a design prototype. We don’t waste it on the deliverable “wireframe”. Digital product development is a marathon, not a sprint.

Argument 4: Wireframes allow you to avoid discussions of taste

If we present a prototype, there’s a fear that the user or client might be distracted by the design. Maybe we made the whole prototype yellow and the client hates yellow. Wireframes are abstract enough that we are able to create enough distance from the final product to be able to discuss the basic ideas as factually as possible. And wireframes are tangible enough that they enable joint decisions on information architecture, user experience and technical requirements. Right?

Unfortunately, this distance actually causes problems. In a wireframe, we breakdown navigation bars, galleries and forms into a representative generic interaction pattern. They are nothing more than symbols that represent a certain type of interaction. However, symbols have to be decoded and interpreted. Everyone sees something different in them. This is how unconscious (and unintentional) expectations of the design are established. The further we move away from the wireframe idea during the design process, the greater the disappointment. The consequence: in many cases the design deviates only marginally from the original wireframes. They become a prescriptive blueprint before anyone has really thought about the form and communication of the content in detail. Wireframes end up backing us into a corner with no way out.

The author speaks to someone outside the picture.
The author speaks to someone outside the picture.

We can’t protect ourselves from discussions of taste by abstracting with wireframes. In doing so, we diminish the importance of the design to an aesthetic layer on which we decide “separately and at a later point in time”. Without the underlying interaction design and its visual characteristics, it is hardly possible today to gain valid insights into technical requirements, information architecture or even the user experience.

It’s important to remember that now more than ever, the entire digital experience is based on so much more than just the content itself. The way that the content is arranged on the page, when it’s presented and how it’s presented are just as important to the product. In order to be able to create great user experiences, we rely on design prototypes as early as possible.

Would you like to say goodbye to wireframes?

Here’s what you need to know:

We’ve found that we’re better off designing the interaction between man and machine in a creative debate from the very beginning. In our experience, this is how brilliant products are made. However, there are two things that you need to keep in mind if you’d like to adopt this mindset.

1. The Process

The first concerns the process. As you already know, digital products have no completion date. The same applies to their design. Release after release, product teams strive to optimize the user experience and respond to the market. The design is part of that and the design is inseparable from it. The first design draft will not be the last. And before it sees the light of day, it will have changed a few more times. Of course, we may strive for perfection, but it’s impossible to achieve. That’s why we start designing in hour one, and we never stop.

2. The Skill

The second concerns the product designers' skills. Moving away from wireframes requires a broad level of expertise. Titles like User Experience Designer, Interface Designer, and Service Designer each focus on different contexts. Some of these roles are so focused that they aren’t backed by a traditional design education. However, a broad knowledge of design and the corresponding tools is needed to consider architecture, interaction and visual appearance all at once. It’s the only way to open up the scope for new solutions. We prefer to rely on specialized generalists. They are able to see the bigger picture and use the tools required to design high-performance products from the beginning.

In order to move on from a world of wireframes, it does indeed take a mindset shift. What I can say is this: We haven’t used wireframes in 4 years and it has only had a positive impact on the products that we’ve designed. Working without wireframes has meant that our team is able to properly pin down a strategy, get valuable user feedback early on, and ultimately design for the entire digital experience. Our products are better than ever. We’ll never go back.

Thanks very much for reading! I’d love to hear your thoughts in the comments and of course if you have any question about the workflow, let me know!


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK