Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

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.

share|improve this question
add comment

8 Answers

up vote 11 down vote accepted

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.

share|improve this answer
    
"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 Mar 21 '11 at 12:40
    
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. –  jameswanless Mar 21 '11 at 16:19
add comment

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.

share|improve this answer
    
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 Mar 17 '11 at 16:13
add comment

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.

share|improve this answer
    
+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 –  Charles Wesley Apr 2 '13 at 20:53
add comment

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.

share|improve this answer
    
Good point about representing dynamic interactions. Let's face it - MS Word just isn't very dynamic... –  gef05 Mar 17 '11 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. –  Gerardo Jaramillo Mar 17 '11 at 17:49
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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

http://www.leacock.com/deliverables/block_diagram_ex2.pdf

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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