How do you make wireframes?

or at least, how I do it!

What is wireframing?

Image for post

Wireframing is what I call the structure of a screen— it’s a blueprint, and a place to ideate and strategize. Sometimes it’s just for discovery and thinking, other times it’s for planning and finalizing. They’re very versatile, and well worth your time to build into your workflow.

They’re typically in gray scale and are boxes and some text.

Image for post

I’ll also be lightly touching on Prototypes, the next step after you wireframe, A wireframe is static and helps you get an idea of that specific screen. A prototype is functional and helps you get an idea of the product as a whole.

Why is wireframing important?

We’re almost to the how-to stuff — stick with me! If you already know it’s important, keep scrolling, but otherwise, I think this is really valuable to know how to convince others to include a brand new step into an already tight timeline.

It creates space for collaboration

I am known for wireframing on the big screen with everyone else. It is really hard to verbally articulate what’s in your head, and starting to draw it out will help others that aren’t designers collaborate in the process.

It creates alignment

You may not have realized this, but everyone already had a picture in their head of what it was going to look like before they walked in the room. Putting your wireframe out there helps others to articulate what they were envisioning and creates the dialogue needed to come to consensus.

It saves time

If you’re collaborating earlier on and getting alignment earlier on, that means developers spend less time changing copy and you run into far fewer surprises. It’s just way faster to click and change text in a wireframe than it is to change the text, push to a branch, deploy into a dev environment and what not.

A couple caveats before we get started:


The following principles apply regardless of the tool you’re using, though the how of it may be different. There’s a whole host of people that think you should start with paper first, but I find paper puts me in a “do it right the first time” rather than an experimental mindset. Other people find the opposite- that once they go digital it starts to feel too concrete. I use Axure as my main tool, though there are many other ones out there

It does take practice

It is a skill. No, it’s not difficult to draw boxes and lines or drag them into file, but it does take time and practice to get familiar with a tool and to learn good content design best practices. This article is covering the mechanics and process of wireframing, not content design best practices.

The phases of wireframing

My wireframes generally go through 2 stages before approval: ideation and development. Today we’re going to walk through the example of wireframing a Contact Form.


This is the phase where I’m just trying stuff. I’ll start generating ideas and plopping them on the screen to start casually getting feedback from others. (This could be a whole article in itself, but make sure you’re talking to people who know that these are ideas and can help you think about them).

Step one: Start by wireframing what you know

Axure has pre-built widget libraries, so my step one is start putting in elements I know I need. Sometimes, that’s just the navigation menu and footer, if it’s a website — that’s ok! It helps you to gain some momentum and get over blank page fright.

Since this is a contact form, there are a few other things I’m reasonably sure I know I need to have, like a page header, an email input, a label for the input and submit button.

Image for post
No comment box? Who knows — we might do something different depending on our context

Step two: Start ideating

Now that you have the “for sure” things in, you can start adding in other elements. I can’t provide ideas for you- that’s just a mixture of experience, research, and pure inspiration. I will probably spend at least an hour looking at how other people have solved a similar problem.

So after some looking around for inspiration, I started pulling other elements in and made a video of working through it.

It’s so hard to watch yourself work
Image for post

I added in a map and directions to our building and a department dropdown to help us more efficiently direct email, plus some phone and fax information.

Things to remember:

  • Figure out what level of detail (aka fidelity) you need- You’ll see wireframes include different levels of detail — are you brainstorming? Lines to indicate text may be enough. Are you trying to finalize and move to development? More detail is probably more helpful.
Image for post
  • If at all possible, don’t use lorem ipsum. If you don’t have any idea of what the copy should be, then you don’t need it. I place copy guidance inside brackets [] to signify the text still in process.
  • Don’t wireframe anything you don’t want discussed in a review — it becomes a distraction. If the navigation bar is not up for discussion, a good tip is to have a box that is labeled with Navigation like I did above.
  • You don’t need to be pixel perfect- Yeah, I spend a little time making sure things are aligned and spaced alright, but it’s usually not perfect, just close enough that it’s not distracting in a review. It is far easier to have perfect spacing with code than it is in most wireframing tools.

Step three: Start Reviewing

I’m a big fan of reviewing early on at this rough stage. It removes surprises later down the road and allows room for collaboration and negotiation.

In the review you should have, if you can:

  • Whoever will eventually approve the wireframe
  • The person who will be building the visual design
  • The person writing the copy
  • The person who will develop

Presenting a wireframe/prototype is really tough though, especially if this is a new step in the process for you. One of my former colleagues, Rachel Maynard, put together this really helpful infographic for reviewing wireframes. I’ve often passed it out before a meeting and reviewed it before opening up the wireframe.

Image for post

The next phase: Development

We’ve laid a foundation and our first review tells us that we’re moving in the right direction — so let’s move!

Step 4: Copy

Depending on your process, you may have handed the wireframe to someone who has written some copy for you now. Start putting it in! This is a great stage to realize if it’s working. If you don’t have someone to write (which let’s be honest is probably true)…start writing something more final for reviewers to react to.

Step 5: Visual Style

You might be working somewhere that has a defined style guide. Depending on how adept your co-workers are at reviewing, you might actually want to wireframe with styled widgets -there’s no reason not to, as long as your reviewers understand that the style is not up for discussion. If your reviewers continually keep getting distracted by the style though, it might be more efficient to use greyscale.

If you don’t have a style guide, collaborate with your visual designer even in greyscale! Is the font size hierarchy what they were envisioning — might they put a call-out box around some important content?

Step 6: Functionality

If you’re using a program that allows you to build interactivity and turn your wireframe into a prototype, the development phase is a good time to do that. For instance, in our contact form, we might want to build the interaction states for an invalid email, invalid 0 character message, a thank you after submitting, and anything else that could happen.

Final Wireframe

Our first review had some feedback that we wanted to include some promises from our customer support and that we didn’t really need the fax information it’s so rarely used, so I made a few more modifications.

Image for post

Step 7: Review again!

By now, you should be just at the edge just before applying final color, typography, and imagery. You can be writing up a document describing the functional interactions to hand off in combination with the wireframes to your developer and the visual designer starts to take what you did and apply their skills to the wireframe.

Image for post

For instance, in this case — the visual designer decided to group the address and directions button together, and to use a little bit of a different styling than I had implied in the wireframe for the sidebar — which is just fine! Let them use their creative expertise. You provided a structure for them. This should continue to be a collaborative effort.

There you have it!

Much of this depends on your process and the type of team you have around you — but the basics are:

  • Get what you know you need on the screen
  • Start playing around with ideas
  • Start building in copy and hints of what the visual design could be
  • Review repeatedly!

Happy Wireframing!

Ashley Crutcher is a Digital Designer at InterVarsity located in Madison, WI. She tweets at @ashleyspixels and enjoys cuddling with her furkiddos, working with yarn, ringing handbells, and thinking too much about everything.

Digital Designer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store