Knowledge Base Articles > The Two Phases of Wireframing
Wireframing is more than just a way to sketch an idea on your computer. It is used so often because it helps answer two common questions software builders face.
The first question that wireframing can help answer is:
What are some ways we can solve problems our customers are having?
The second question that wireframing addresses is:
How do I know if this solution actually solves their problems?
These questions can be split up into two distinct phases: the ideation phase and the validation phase.
The first question, trying to figure out how your product can solve customer problems, lives in the ideation phase of the wireframing process. This is where you generate as many ideas as possible in order to iterate toward better and better solutions.
The ideation phase is one of the few places where quantity matters as much as quality. The ability to generate multiple ideas and variations on a single idea allows you to see the faults and highlights of each. The more designs you put down on the screen, the more individual ideas you have to choose from. The root of "creative," after all, is "create"; that’s the strategy here.
A helpful way to think about this phase is to flip convention around. Focusing on creating only good ideas may restrict you; instead, try to create as many bad ideas as possible. This will remove creative blocks and free you up to just produce. You won’t get to "aha!" without going through "oh, no!"
A good way to demonstrate what this phase looks like is to show an example. Here is a series of wireframes that I created in about 25 minutes using Balsamiq (sped up 4x).
I gave myself a simple challenge of designing a to-do list app for a mobile device.
I did no preparation beforehand (not recommended) and don't consider it "finished," but it still captures the process in action.
Here are a few snapshots from the video that show the progression:
As you can see, you can create several ideas in a short amount of time if you don't get hung up on the details.
The second question, determining whether your proposed solution will be successful, belongs to the validation phase of the wireframing process.
Whatever your role in the software development process, you are lacking information and knowledge required to build the best solution. You may be missing essential information about your customer, or the limitations of the technology, or some marketing data. In any case, to refine and optimize your solution, you need involvement from other stakeholders.
Showing your wireframes to others allows them to validate and improve your ideas.
The validation phase shouldn’t be thought of as the place to get "sign off" or approval to start building right away. If you’ve done it right, your wireframes should invite conversation. If they look too polished and "final" you may not get very helpful feedback. Wireframes should communicate "here’s what I’m thinking..." when you show them, not "this is what we’re going to build."
Assume that the people who you are showing your wireframes to have knowledge that can help you make them better. Your job is to get it out of them.
You don’t need to show all your ideas during the validation phase. Here’s where you can narrow down and focus on the better ones. That said, it’s perfectly acceptable to show variations on an idea or even different directions completely. This reinforces the point that wireframes are a conversation starter, not a finished product. You may want to keep a few alternate ideas in your back pocket anyway in case your preferred ones don’t go over well.
In this phase, it’s important to think of your wireframes as communication artifacts. Their job is to help other people understand your ideas. Visuals are very effective for conveying ideas, which is the true power of wireframes.
Separating your wireframing process into these two phases will help you create better wireframes by letting you focus on answering one question at a time.