The design, development, and testing folks are having a conversation at the moment about requirements.

Part of the conversation is about the purpose and use of wireframes. Our change analyst is strongly opposed to using wireframes as part of the requirements for either development or testing. They are to be used for "additional information" only when necessary - "something to refer to" for clarity.

In short: use written requirements, not visual.

Should wireframes be used as part of the requirements-gathering and documentation process?

Have any of you ever worked on a team where wireframes were the primary requirements doc for development and/or testing?

Edit: I do have a bias in favour of using wireframes as formal requirements documentation. I spent a couple of years in a setting where they were the sole form of documenting requirements - development did not start until the product owners (Agile setting) signed off on the wireframes. Very efficient in that setting.

10 Answers 10


I think you risk the requirements vs design debate here. Wireframes are pretty important but I think it depends how you conceptualize them. The following is my own opinion but backed by pretty standard industry processes in my experience.

  • Requirements should generally be written only because you are describing what a solution needs to do. They should be of sufficient detail to describe clearly any steps that have to happen and should be broken down into logical buckets, depending on the type of product they are for.
  • Wireframes are part of the design process because they describe how the solution needs to behave to meet the requirements. Sometimes you might need to develop a mental map or a node diagram, or draw something to get a client to more clearly describe their requirements, but that is not the purpose of a wireframe.
  • In projects where someone has drawn out how an application should flow and/or built wireframes (which essentially begin placing elements on a UI) right upfront, it invariably biases the design process and IMHO usually ends up being changed substantially or thrown out altogether.

Requirements are usually (not always of course) written by a business analyst or PM and not by a user-centered designer. Sometimes these roles overlap and people can do both well, but where the roles are differentiated, wireframes as part of requirements usually don't work in my experience. Out of necessity, they come afterward, when the client has signed off on what the product needs to do, not how it should do it.

  • "where the roles are differentiated, wireframes as part of requirements usually don't work..." I think this is a very good point James. I do both (mostly BA), and as a result there is a natural tendency (bias?) to want to include/use the wireframes as part of the requirements. But thanks for the thoughtful delineation - always good to be reminded of the basics! --G
    – gef05
    Commented Mar 21, 2011 at 12:40
  • 1
    I do both jobs where I work (and PM the project usually) too Gary, so I hear you. I find myself tempted to jump right to solutions sometimes too. A project I'm currently working on, where I'm only doing UX work (not PM and not BA) reminded of the value of delineating these tasks. They did a 'process' flow first thing with the client, then requirements full of gaps and now I'm going back to the drawing board and doing the flows from scratch because they're all about what they think the data model should be and barely factor the user in at all. Commented Mar 21, 2011 at 16:19
  • I would add a major flaw in wireframes, they describe a solution to a problem (the requirements) in a narrow fashion. I usually argue, that your requirements should be written in a way that if taken to an [en.wikipedia.org/wiki/Automated_attendant] Automated attendant system, they would still hold water... so can your wireframes describe the problem in such a manner?
    – Ayyash
    Commented Dec 13, 2015 at 16:33

I use Storyboards in PowerPoint in semi-high fidelity. I find written documentation has major flaws.

  1. People can't react emotionally to interactivity by imagining it from text. You can't write a paragraph on how something will work and have people understand the nuance of the interaction design. It's like writing "The graphic design will be beautiful using lots of purple". What does that mean? How can you define it without showing it?

  2. Language sucks. I have way fewer arguments in person versus in email. Email (text communication) has way too many chances for misinterpretation. When you are together, and looking at something visual, things go smoother. Additionally, many engineers I know are not English as a first language speakers. Text is very often misinterpreted.

  3. You can't test text. You can test a storyboard and put it in front of people to get reactions. Text doesn't work that way.

CAVEAT: All companies have quirks and special circumstances. You have to find what works for you. Just don't let people tell you something you know is wrong. If you have to, do both and secretly give the storyboards to engineers.

  • Glen - I agree with your three points, but especially #2. I've successfully handled requirements gathering in written format for $75M projects, so I know what I'm doing, but it's a constant tension to state things in a way that matches the clarity of a visual.
    – gef05
    Commented Mar 17, 2011 at 16:13

My frustration as a BA is the lack of clarity between "Requirements" that are testable units and "Design" which, when created as part of the requirements actually BECOME requirements. When the business signs off on a low-fi or a high-fi wireframe, they have made that visual their requirement. Now I'm writing testing scripts to ensure that the wireframe is generating exactly as shown in the picture. Talk about granularity!!Requirements should be about the FUNCTION of the application, not the visual design unless the design has a legitimate business need to covered - like ADA, Marketing standards, or identified productivity enhancements.

More often than not, business and developers rely on the visual because they cannot conceptualize their end product without it. It's the difference between reading a book and watching the video of those requirements. It's a slippery slope of getting married to a design and the business starting to dictate "how" that design should act (save buttons, error messaging, data collection, navigation, etc.) As much as developers should not be dictating UX, neither should the business, unless they are in the business of UX and design and then I'd wonder why they aren't writing code themselves.

The big groan is often gather and document requirements faster so development can start which begs the question of why write them out at all? If developers cannot read requirements and start to structure development without design, then it seems likely that they don't care about reworking data and design rework is far more uncomfortable to change. Being agnostic to requirements gathering means open opportunity for agnostic design - design not tied to a platform and it's constraints. Creating the process of signing off on wireframes, you are setting the business up to accept what you are willing to give them instead of giving them what they need. Then the process ends up about the pretty pictures and not about the function of the application.

  • +1 "It's a slippery slope of getting married to a design and the business starting to dictate "how" that design should act" Excellent point Commented Apr 2, 2013 at 20:53

Defenitly... I think is essential for your UI team to have a wireframe to see all the different interactions you need to display on the project.

Some people my say that it should be suficient to have a written description of the project, but you can´t sometimes get the whole picture of a proyect with just words.

Specially with dynamic wireframes it more easy for designer for example to have an Idea of what a menu should do.

It is also great to work with clients, since they have a clear picture of what your team intend to program for their project.

This will save you a ton of time on the programming side of thing and UI interactions for me a good wireframe is the graphical representation of a good written document.

There is no doubt in my mind the value of a good, detailed, interactive wireframe.

  • Good point about representing dynamic interactions. Let's face it - MS Word just isn't very dynamic...
    – gef05
    Commented Mar 17, 2011 at 16:16
  • Yup! interactive is the way to go! if you have budget you can buy a really cool software call Axure, it will generate you the technical documentation as well. Commented Mar 17, 2011 at 17:49

I found the ideas found in the book "Prototyping: A Practitioners Guide" to be a good example of how sometimes a written MRD isn't as useful as it used to be, based on the idea that sometimes showing, is better than telling. Granted the books specifics are about prototyping, I feel like the same ideas can cross over to wireframing as well.

  • Prototyping is generative: Meaning, as you go through your prototyping process (or wireframing), you're going through hundreds of ideas. Some brilliant, and some not so brilliant. But the less brilliant ideas can be a catalyst for brilliant solutions.
  • Prototyping communicates through show and tell.
  • Prototyping reduces misinterpretation. Take a 60-page requirements document. Bring 15 people into a room. Hand it out. Let them all read it. Now ask them what you're building. You're going to get 15 different answers. Now imagine trying the same thing with a 200-page MRD - it gets even worse...
  • Prototyping creates a rapid feedback loop, which ultimately saves time, effort, money, and reduces risk.

With all this in mind, the argument against this would be, sometimes prototyping/wireframing can also be overkill for certain projects, so really, it all really depends on the project.

  • What is an MRD? (tip: Write it out with the acronym after since you are addressing a larger audience on this site). Commented Apr 23, 2014 at 17:22

Wireframes are not requirements documentation. Requirements documents are not wireframes. They both depend and influence each other, however.

I find that they work best together in parallel. In other words, both evolve together (as opposed to one being finished before the other starts).

You mention that you uses wireframes as requirements in an agile enviornment. I think that's likely the exception. Ideally, everything would be done in an agile environment.

In that scenario, wireframes are really napkin sketches. They are an internal document to communicate an idea so that it can immediately get built.

The great thing about Agile is that (IMHO) when done right, it greatly reduces the need for documentation in general and, in a way, makes this particular question less relevant.


Absolutely not - wireframes do not belong in requirements.

Wireframes are a great way to:

  • Generate requirements
  • Design solutions to requirements

But to put them in the requirements is a nightmare, that will lead to confused, muddled thinking and documentation (often conflating form and function).

This is especially a problem in regulated environments or contracts - look at this way, if the user interface changes a drop-drop list to a list view:

  1. The requirement is no longer satisfied and is by default a regulatory or contractual failure. The product still works fine but the paperwork is now a legal liability.
  2. The documentation has to be redone every time the user interface changes - this is insane.
  3. I worked for a company before that was crazy enough not only to put wireframes in the requirements but also in the corresponding tests! That madness meant that when the user interface was overhauled with new designs and toolkits, all the documentation had to be redone (that they hadn't accounted for in their project estimations).

I'm assuming you just mean user interface wireframes. Block diagrams, flowcharts etc. are essential.


The end-product you're building is a web application.

Wire-frames can get you half way there with little effort, so it makes sense to use wire-frames as requirements as long as they contain adequate granularity between steps.

Otherwise I found poorly done wire-frames can be misinterpreted almost as easily as written requirements.

But, written requirements are still essential in documenting all the flows. Without them, it becomes difficult to do structured user-acceptance-testing and QA testing.


This is where I believe your requirements can become resourceful - Building block diagrams and flowchart.


Here,It explains the process in a flowchart, which is once again better off than just documentation. Using Wireframes need time,budget to work around.But using block diagrams and flowcharts are more meaningful and helps other developers and team members to get engaged with the documentation.

Mostly people do not like looking at textual information which under my experience really does not entice anybody to look at it more than 10 minutes. We have done a project facing Client where it majorily benefitted by showing wireframes in parallel to textual data. People started to understand what we are trying to document in. But it takes lot of effort. So ideal way to keep resources intact is to use flowcharts and block diagrams to make it interesting.


First of all requirements have TYPES. Business requirements should not be described in wireframes. A specific client requirements can be described with wireframes. Requirements form a hierarchy with traceability between requirements and the types of requirements. So you will have to state which type of requirement.

If you mean business requirements:

If you are doing a smaller project where the main focus is e.g. an app or a user interface for a webclient then of course wireframes can be handy.

When the technology is a technology where layers are fuzzy e.g. PHP as in e.g. WordPress sites or the older Asp.Net Forms technology then wireframes can be handy because the logic is intertwined with the output.

In most other situations however you preferably do not want wireframes.

  • An important reason is that you want the business to clearly state what things are. E.g. "what is a department", you want this discussion not "should the pulldown menu make it possible to edit departments"
  • An important reason is that you want your team to think about dependencies e.g. is there a relation to a cost center and yes: what is this dependency. Are there other dependencies. How does the domain model look like, which often will have hundreds of properties which do not end up on a screen but which are part of the core business logic.
  • An important reason is that a solution is that what lives on the business layer. The business layer contains the business models and logic and clients by definition not. The business layer can have a programmatic API and e.g. a REST API. Which in turn can have hundreds of different webclients, mobile clients, serverless components, commandline tools etc. So by using one specific wireframe you force people in a way of thinking that in the long term will not provide beneficial because you reason the other way around: from a client perspective, which does not contain business requirements.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.