There’s a basic method for building great products and experiences — a design process. It is not something step by step that you have to follow verbatim. Instead, the design process is simply a continuum where you start with very little details and a general idea of things, ask questions, and then fill in more and more details and granular thinking as you go along.
This approach of starting with broad strokes and move towards more detailed thinking deals with design “fidelity.” In almost any design project you move from low fidelity to high fidelity. Let’s first define what we mean by “fidelity.”
A ux design artifact is anything that communicates thinking and design intention. It can be a Photoshop doc, a wireframe, a hand-sketch, or a whiteboard diagram from anyone on the team. Fidelity refers to the level of details, nuance, and amount of refinement put into any design artifact. Fidelity can run the spectrum from an ugly hand sketch on one extreme, to a pixel perfect photoshop file on the other.
Here is an example from a past project of mine where myself and two other UX designers used quick hand sketches and giant post-it boards as paper prototypes to get our ideas across and foster collaborative thinking. We were building a app for the very first iPad, months before it launched in 2010, and had only a cardboard mockup approximating the device’s dimensions to use as our “prototype.” You’ll notice in this image there are many design artifacts on the table with varying levels of low fidelity.
From low fidelity to high fidelity, there is a huge range of steps, decisions, and levels of detail that you’ll want to move through to make a great product. Essentially those steps are all questions that help you dig for answers to better understand what you’re designing. Design artifacts, whatever the fidelity might be, are essentially tools to raise assumptions into question and aid team discussions. Once you put ideas down in paper or pixels, you can then have the meaningful conversation amongst the team and discuss things like:
This question and answer approach is a second dimension to the process, which I’ve poorly labeled “concept” for now. As the concept decreases from high to low details, the focus of your efforts shift from more vague “what are we building” questions, to very specific interface and interaction considerations. As a project progresses, you refine an understanding of the concept, and gain a clearer picture of how all the pieces of the product fit together.
When first starting a project, the more questions you can ask and addressed upfront with design sketches before you get involved with customers and user testing, the better off you’ll be. Why? Because you can work through many issues upfront that you’d later burn time and money revising or addressing later on. Even more importantly, working through questions in sketches and low-fidelity helps build consensus among a team, so that everyone can get behind a common vision. There’s a ton of value in getting together and asking “does that need to be on this screen” for the simple purpose of coming to a group consensus of “yes!” Testing is of course a huge part of the design and development process, but not at the expense of rapid internal iteration.
Once you and your team move through all that churn of getting a product to a place you feel makes sense, then you can move into user testing and refine your product based on customer input. You can also focus more on the high-fidelity decisions of page layout, design patterns and interactions. Style, texture, screen real-estate, and especially considerations like device resolution and layout (responsive vs. fixed, etc.) begin to come into play.
Sometimes, teams go down a very different route, and jump into pixel-perfect comps too early, before really understanding what they’re building. Expending time and cycles on drop-shadows and interface polish before hand sketching, in my experience, always leads to problems down the road.
When you go through the design process backwards, you will almost inevitably fail to answer key questions, or discuss some fundamental aspects of your product as a team. There’s always exciting uncertainty in building something new. But there’s a difference between uncertain versus haphazard and messy.
The goal of following a process or method like this is to make sure that you articulate a clear, wide and broad vision before jumping into pixels or code. This ultimately leads to a design process that starts with low-fidelity at a high, conceptual level, and gradually moves to high-fidelity artifacts at interface level of details.
Along these curves of decreasing conceptual thinking, and increasingly fidelity fall different design artifacts or tools used to communicate pieces of the project:
Anytime we talk about design in the abstract, there are certainly going to be exceptions. So much depends on what project you’re working on, the type of domain you’re dealing with, and your team’s skills and backgrounds. A simple design/coding duo, or a dispersed team with offshore help, will have to approach things different, and especially for a UX designer, the artifacts you create are merely communication tools.