• Wireframes are becoming less relevant — and that’s a good thing
  • By Sean Dexter
  • Translation from: The Gold Project
  • This article is permalink: github.com/xitu/gold-m…
  • Translator: hanxiansen
  • Proofreader: Fengziyin1234, Xiantang

As time went on, I found wireframes less and less useful, and I wasn’t alone. Since the term “wireframes” isn’t exactly defined, it might be worth clarifying what this article is about. While there are many prototypes that can detect different dimensions of fidelity, THE one I want to focus on is the one that first comes to mind when people hear the word “wireframes.” The wiframe here is neither a sketch nor a fully detailed prototype, but a typical “in-between” state (a deliberately unstyleable artifact that exists in digital form and is used to render the “skeleton” of an entire page in black and white tones). Prototype wireframes attempt to accurately represent the layout and information framework, while deliberately not trying to reproduce every detail at the visual level, and sometimes even at the content level.

In I participate in offline or online discussion, I surprisingly found that people still wireframes may be defined as the basic steps in the links of design, although this attitude seems to be in decline, but I still can hear everyone – from first professional designers to industry leading institutions, both on the necessity of “wireframe stage”, These arguments usually contain the following aspects:

  • By focusing on utility rather than aesthetics, wireframing prevents stakeholders from steering the meeting by getting bog down on unimportant details (such as button color), and allows users to focus on interaction rather than visual presentation during testing.

  • Wireframing takes less time, keeps the problem at a conceptual level, and prevents us from holding on to or spending too much effort in one direction.

  • Another (more corporate) point of view, which is a bit different from the first two, is that wireframing is a tool that can be used to document interactions in detail without requiring extra effort on the design side.

That’s not to say that everyone actually wireframes, but admit that when they’re not, people tend to keep their voices down and their eyes wander. It’s not that they don’t want to; They simply cannot do it every time because they are constrained by the organization, the stakeholders, or the project itself. But the mindset that wireframes can’t be avoided, and all sorts of ideas about the benefits of wireframes, may be misguided. While I don’t deny that there are times when wireframes are useful, those occasions are rare and dwindling. Driving this change are a number of shifts in industry thinking and practice that are worth examining.

Changing product development methods are changing the way people approach design

Agile product development encourages us to use less linear processes. Instead of starting with basic elements that fully cover the entire product and then building layers on top of them, this approach shifts the focus to smaller, more frequent “vertical” slices that deliver full implementation.

This also includes fully implemented design, which makes it important to consider visualization, information architecture, and interactivity at the same time. In agile development teams, each iteration takes place in days or weeks, not months or years; In this development scenario, there is less room for the kind of large-scale mapping phase that takes place early on and often involves people drawing a bunch of wireframes.

Lean UX is a resulting improvement process that seems to be gaining traction. In Lean design, heavy design work is ignored or omitted altogether in favor of collaboration on the product itself. Lean design also refutes the idea of wireframing as a documentation tool. It suggests that the screen layout of the actual product can serve as their document, and that the design components you create yourself will become temporary items — as long as the information they contain exists in an accessible way in the actual product, they can be put aside. Other relevant information can still be recorded, but only at design time or after.

Usability and information frameworks do not exist in isolation

It’s a well-known fact, but I’ll say it again: the visual representation of elements in an interface affects how they are perceived by the user. If the drop-down menu looks like a form area, it may misunderstand its function. If the appearance of the menu title makes it difficult to distinguish it from the menu item, the user may miss it. Color and contrast play a huge role in directing visual attention. If you’re doing usability testing on a wireframes, you won’t be able to do a good job when you finally change the look and feel. And at that point, you may need to make more changes to the layout to better accommodate the visual effects. Users may only focus on the visual elements, and there’s nothing wrong with them doing so, and making everything grey doesn’t necessarily reduce that risk. Asking questions about understanding, and testing in a way that completes the task, reveals usability or information framework issues more than a verbal comment. Concept input can be achieved with any fidelity as long as you set expectations well and pay attention to the request for feedback.

Getting stakeholders to look at wireframes rarely works

Meetings can be frustrating when a stakeholder is obsessed with the color of a button or copy. This I understand. But can you really solve the problem by deliberately not using high-fidelity images and filling them with Lorem Ipsum everywhere? Or are you just putting off solving the problem? Do you like low fidelity because it makes it easier for people to understand and comment? Or is it: it makes it harder for others to understand, and we like it because it allows us to put our expertise above others’ and protect ourselves from criticism? If stakeholders are less interested in evaluating information architecture and more interested in other things related to their expertise, then why would you want to be confrontational? You are the information architecture expert, they are not; Any changes that need to be made to the layout should be made clear by testing with users.

It becomes faster and more accessible to high fidelity visual presentation

A few years ago, Photoshop was the king of UI design, and everyone was racing to see who could add the most detailed, realistic textures to a given page. At that time it was justifiable to say that wireframes had the advantage of saving time. But today, our design tools are built specifically for UI design (think Sketch, Adobe XD, or Figma), and they greatly speed up and simplify the process of managing and updating designs at a global level. There’s no reason it’s harder to change the layout after you’ve set the visual style than before. For mature design organizations, the combination of designing systems and the component libraries that support those systems removes almost any excuse. And even if your organization is immature, you’ll probably still have a UI toolkit that matches the UI framework used by the developers around you. It also helps that today, even the most complex visual aesthetics are still relatively simple. If your button is just a blue rectangle with rounded corners, how much time would you really save by deliberately turning it gray?

Do wireframes still make sense?

It makes sense under the right circumstances. For example, you might draw wireframes for the following reasons:

  • If you do have a visually complex product (like a mobile game), the art is going to take a long time to create, and you have to figure out how the product interacts without having to create the art. Even so, you can try to achieve style similarity.

  • You use them as an exercise to help people understand the information framework independently (hopefully as a one-off rather than a repetitive part of product development).

  • You want to draw or test information frames, but you rely on someone else’s visual design (which is not ideal!). Or, you are held back in some way by the visual capabilities of the tools available to you or by your personal skill level.

  • You’re in an outdated waterfall flow or proxy environment, and you don’t have a lot of autonomy over the process, which is not good, you have no way.

I’m sure there are many other possible scenarios and exceptions, but I think it’s probably not common for most designers today, and if you think that traditional wireframes are only solutions that really fit the problem, then you’ll find that they can often be avoided — and that’s OK.

If you find any errors in the translation or other areas that need improvement, you are welcome to revise and PR the translation in the Gold Translation program, and you can also get corresponding bonus points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.


Diggings translation project is a community for translating quality Internet technical articles from diggings English sharing articles. The content covers the fields of Android, iOS, front end, back end, blockchain, products, design, artificial intelligence and so on. For more high-quality translations, please keep paying attention to The Translation Project, official weibo and zhihu column.