These are questions that have been bugging me and our team and they have been the subject of many articles and debates. As a UX dude, I generally vote in favour of such an artefact. At the same time, I have met opposition from co-workers. That’s why we have tackled this issue at our agency Hinderling Volkart.
An easy answer to the initial questions would be:
Well, this solves the questions on a philosophical level but doesn’t provide you with guidance when working on a real-world project for a client. That’s why we agreed on setting up a whitepaper to help our process and workflow in our team. Here is what we did and what you could do, too.
1. Talk, talk, talk and gain a common understanding
Debating the topic in our design team revealed that there are varying perspectives and opinions when it comes to wireframes and their purpose. In the end, wireframes are only one artefact in the entire design production process.
Thus, questions arose regarding the differentiation of wireframes, mockups, prototypes and design, the general wording and the definition of these terms.
Furthermore, there is not one way of doing one or the other, and the lines start blurring even more when you add the aspect of fidelity to the equation. That’s why you need to…
2. Agree on artefacts, their definition, naming and attributes
We evaluated potential project artefacts, their attributes and relevance in the design production process. Each project is different. Thus, based on requirements, the scope and nature of a project, we select artefacts we believe to be valuable to the final and desired output and outomce such as:
- Screen Designs
- Design Systems
- Design Styleguides
To select relevant artefacts and deliverables we have defined attributes for each artefact:
- What: Type and name of the artefact.
- When: Point of relevance or delivery in the process (see below).
- Why: Definition of why the artefact is needed in the first place.
- How: Form, fidelity and required know-how and resources to produce it.
- For Whom: Target group and recipient (e.g. internal or external stakeholder) based on the purpose of an artefact.
3. Align artefacts with your process
We have lined out rough steps in the design production process to have a better and common understanding of what artefacts to select at what stage. This categorization is neither to be confused with a project management methodology nor is it meant to represent all other activities such as testing, content production, programming etc.
1 — Make first ideas easy to understand
Sketching and low fidelity wireframing
First ideas core product features, core use cases and vision made tangible (low-fidelity and mainly aimed at the core team)
Paper, whiteboard or simple digital wireframes, sketches or low-fidelity prototypes
2 — Make a product vision tangible and relatable
Designing moods and mockups
A realistic visualisation of your design vision of the final product (mainly for external stakeholder or internal decision makers)
Presentation, mockup, moods, prototypes etc.
3 — Define further product features
Further sketching and low fidelity wireframing of further product features or relevant use cases
Ideas for deeper level product features and use cases visualised (low-fidelity)
Paper, whiteboard or digital wireframes, sketches & prototypes
4 — Think further features through and make them usable
High fidelity wireframing & prototyping
Detailed representation of deeper level product features, functionalities, user flows and use-cases
Paper, whiteboard or digital wireframes, sketches, user-flows, and prototypes
5 — Finalize and design everything for production
High fidelity detail design
Detailed visualisation of the final product and its features to the very last detail required
Detailed screen design, style guides, design systems, animations, design components libraries and assets and a final product or visual base for code
There are countless terms and definitions of artefacts used in a design production process. Get your team together, talk and create a common and unified understanding. Define attributes for your deliverables to help you judge their value and need in a specific project.
Let’s revise the initial question and answer it once and for all:
Do you need wireframes? No, you don’t.
Nevertheless, they may help your process and before you abandon them for good, understand why, how and when you do or don’t want to use them in the first place.
Feel free to share this post, follow me on Twitter, find more of my articles or get in touch:
If you would like to read more from Hinderling Volkart and our team, give us some claps and follow our publication — THX: https://medium.com/hinderlingvolkart
Note: Thanks to Dan for the contribution. Originally published on Medium.