Wireframes and prototypes: a waste of time?

3 Aug 2010 - 9:18am
3 years ago
27 replies
3271 reads
Nancy Roberts
2008

I had a disheartening discussion with a programmer at our office yesterday. He felt that we should not "waste our time" with prototypes, or even wireframes! He said that our creative director found the wireframes limiting, and ended up giving back to us exactly the layout that was provided in the wireframes. I explained that the process of wireframing and prototyping helps work out the flow of content, the page requirements, online interactions,  and serves as a guide for design. And I said that many designers I'd worked with had been able to interpret the wireframes just fine. But in essence he was saying skip a good portion of the IA phase of a website project. 

When I asked, if not wireframes and protoypes, what do you do? He said: just a word document with an outline (for structure) and the actual designs rather than wireframes. I agree that collaborative prototyping makes sense, but I really feel strongly that the wireframe/prototype stage saves a lot of misery  later in the proejct.

I'd love to hear from you all: have you had similar discussions? If so, how have you handled them? 

Comments

3 Aug 2010 - 9:46am
alexcarr
2010

Just putting together a document would assume that a wireframe is just a visual aid for something that could easily be written. Perhaps you can explain to the programmer that you are not just mocking up a word document but you're going through an iterative process of discovery just within the wireframing process itself. Deciding what works and what doesn't. Validating the hierarchy you outlined in text. Etc...

Make sure he understands that there is more going on during the wireframing phase and he is only seeing the end product.

On another note: wireframes and prototypes have their place. Not every project needs them. Some projects do. If its going to help finish the project then they're not a waste of time. You just have to decide what projects warrant them.

22 Nov 2010 - 12:05pm
Rhonda Ranney
2010

I agree, it depends on the complexity of the project. I have developed some pretty large eLearning modules and without wireframes, it would have made life very difficult for the proofreaders, SMEs, stakeholders, etc, to all have a clear picture of what I was designing. The wire frames set the ground work for the project. Since much of this work is collaborative you need that base line, then when the feedback gets tossed around.

It doesn't sound like he is downing the process itself, but maybe the actual wireframe format?

I personally have used different wireframe formats for different projects, depending on who I was working with and what their needs were. Ie. Visio worked great working with the eBusiness team, however powerpoint was prefered by a co worker for a quick mock up.

Bottom line, try a format that works for both of you, as long as you are able to map out what you need to and the process doesn't get compromised.

Good luck,
Rhonda :)

On Aug 3, 2010 1:58 PM, "alexcarr" <wrinklefull@gmail.com> wrote:
> Just putting together a document would assume that a wireframe is just a
> visual aid for something that could easily be written. Perhaps you can
> explain to the programmer that you are not just mocking up a word document
> but you're going through an iterative process of discovery just within the
> wireframing process itself. Deciding what works and what doesn't. Validating
> the hierarchy you outlined in text. Etc...
>
> Make sure he understands that there is more going on during the wireframing
> phase and he is only seeing the end product.
>
> On another note: wireframes and prototypes have their place. Not every
> project needs them. Some projects do. If its going to help finish the project
> then they're not a waste of time. You just have to decide what projects
> warrant them.
>
> ((

3 Aug 2010 - 10:12am
sshamsud
2010

If you know the markup language then I would recommend HTML pages as your first step in your process rather than wire frames. This model works for me well. Your HTML pages need not required to be with good aesthetics (at this level).

This model helps to do more iterations in HTML pages itself, later you can also add aesthetics, and visibility of page flows was high. Especially when you're adding any additional features in your existing system then this model really suits well :)

3 Aug 2010 - 10:22am
Kevin Brown
2010

As alexcarr pointed out, it all depends on the project as well as the client. However, even when wireframes are delivered, heavy disclaimers should be attached that they should be considered recommended guidelines for content and layout concepts rather than the 10 "This button must go here!" commandments etched in stone. Ideally, wireframes should be accompanied by written explanations of the logic used to create them. This fosters further discussion and allows others to contribute their original ideas while still playing by the same logical rules regarding flow, content, hierarchical structure, etc. It creates more work, but only creating word document robs the designer (a breed that, by nature, tends to be very visual) of the opportunity to visually work through their own logic and content layouts. Many of my better ideas come from simply staring at a "near-done" wireframe and forcing myself to tear it all down from the perspective of a first time user.

3 Aug 2010 - 10:33am
Brad Ruiter
2010

I have such a love/hate relationship with developers.  What developers often tend to forget is that wireframing exercises are not  just for them, its for the "customer".  

Wireframing and prototyping allows the customer to get in the mode of what the "end state" could and should be.  Development organizations are often a bit myopic in their view and forget the people that pay us want to participate in the design/development process and this means what we do becomes that more important.

These exercises aid in the journey of understanding for both the client and the team without writing lines of experimental code.

3 Aug 2010 - 10:36am
mrbluj
2010

I would stress the fact that when he programs does he not have a creative process to get formulas to create the necessary functions, classes and strings to make the program work. I am teaching myself back-end programming and using pseudo code is a form of that creativity structure for programming.

 Pseudocode is a compact and informal high-level description of a computer programming algorithm that uses the structural conventions of a programming language, but is intended for human reading rather than machine reading. Pseudocode typically omits details that are not essential for human understanding of the algorithm, such as variable declarations, system-specific code and subroutines. The programming language is augmented with natural language descriptions of the details, where convenient, or with compact mathematical notation. (via wikipedia).

So my suggestion would be to relate how we as front end web designers use wireframes as our pseudocode to map out user experiences FIRST and create digital strategies before solidifying the design. Information Architecture is quite vital and as interaction designers wireframing and prototyping gives us the rough draft to perfection. If a structural engineer just by passed their organizational system we would have buildings falling with the smallest shake of the earth, therefore we plan out websites using this method so a design makes most sense to the end user!! I hope this helps!!

3 Aug 2010 - 10:52am
Santiago Bustelo
2010

Design is finished not when we like it, or the client / stakeholder / boss approves it, but when users do what we intended.
Prototyping and testing is the way to achieve that goal.

The IxD/IA process also let us have analysis instead of opinions. It doesn't matter what we "feel" about the design. And definitely, it doesn't matter what a designer or a programmer "feels" about the process itself.

About the creative director finding the wireframes limiting: if actually true, there's room for some exercising there. One that I may suggest for him/her and his/her team: take some final designs, and wireframe them. If you can feed them some designs that are very different on the "surface" but share the "same" wireframe, even better.

--

Santiago Bustelo
IxDA Buenos Aires

3 Aug 2010 - 11:35am
Gabby Hon
2006

Nancy, you're not dealing with a process issue, you're dealing with a polticial issue.

What both the programmer and the CD (by way of the programmer) are telling you is that they don't feel they are being heard: by the company, by other team members, by the bosses -- who knows, but they feel they are being left out. At some point along the way, the team has lost cohesion.

This isn't about wireframes or prototypes--they're the fall guys in this scenario.

Is this a problem you can solve on your own? I'd say probably not. Is it worth raising to your own manager a la "So here's what I've been hearing about the process, but I don't think it's really about the process--what do you think?" -- well, sure, why not?

Is it worth approaching the CD directly and trying to understand his point of view? Maybe. But again: this isn't about process or artifacts or deliverables--it's about people.

I don't know what your level is in this organization, but it sounds like you'll need managerial support to even start to address the deeper issues.

3 Aug 2010 - 11:59am
minimalist
2010
Agree with above post. Sounds like a usability governance issue. In addition to turf concerns, tech may likely see you as 100% risk. They don't typically get praised or faulted for usability (short of catastrophe), particularly if there is a UX person. In that way, every bit of your "meddling" (in their eyes) poses a risk to delivery of *features* which is often their greater focus. I second the other post -- that they're looking to your deliverables as a contract for what they build, but it sounds like you're looking to use wireframes as analysis tool, and rightly so. Are you tasked with trying to establish a user-centered design approach there? - m
3 Aug 2010 - 4:05pm
Robert Skrobe
2008

Nancy,

I think Gabby nailed it. Making some assumptions, I'd say your work culture doesn't respect the deliverables, and trying to convince them otherwise might be a futile exercise.

Perhaps you can contribute differently? Have you asked what's missing from their current process that would improve the work?

  • R
3 Aug 2010 - 11:49am
annabellyeo
2010

Hi Nancy,

What a terrible conversation!  In my 10 years of being an IA I've never encountered anything like that.  I agree with Gabby - these are about politics and people.  Wireframes and prototypes are a great tool for showcasing and testing early concepts.  It is much easier/faster/more efficient for me to fire up Visio and update my wireframe than it is for a programmer to re-code changes that have been made by the client.  CDs also like an entire landscape/blueprint of all the features and content they are working with so they can design - which is also what wireframes do.

I must admit that it sounds odd having a CD and a programmer gang up on you like this.  Usually in my experience they are on opposite ends of the spectrum :)

I would engage in your CD earlier on in the process and colaborate in the "discovery" phase.  That way, it will give him/her the idea that your wireframes reflect the thinking from the both of you and perhaps he/she will feel less pigeon-holed.

Good luck!

~Anne

3 Aug 2010 - 12:05pm
monkeyshine
2010

I once worked with a company that created clickable HTML outlines rather than conventional wireframes and, I confess, I preferred the method because it allowed the team as well as the client to stay focused on the structure and hierarchy of content rather than layout. It is nearly impossible (particularly for clients) to not get distracted by layout in a wireframe.

No prototypes? Hhmm...I don't want to jump to conclusions but I wonder if your creative director is having some control issues? I'm saying this as an art director so I don't know if that gives or takes away credibility. :)  I think each project is different and requires different tools. 37Signals go straight from white board to HTML...they don't even bother with designed mock-ups. It works for them but it isn't a solution for every case. I think at the very least you should be in a room with your creative director and a white board, working out the structural flow of the project so that you both agree that the business and interaction needs are being satisfied.

Good luck.

Deanna




On Tue, Aug 3, 2010 at 9:15 AM, Nancy Roberts <nancyc.roberts@gmail.com> wrote:

I had a disheartening discussion with a programmer at our office yesterday. He felt that we should not "waste our time" with prototypes, or even wireframes! He said that our creative director found the wireframes limiting, and ended up giving back to us exactly the layout that was provided in the wireframes. I explained that the process of wireframing and prototyping helps work out the flow of content, the page requirements, online interactions,  and serves as a guide for design. And I said that many designers I'd worked with had been able to interpret the wireframes just fine. But in essence he was saying skip a good portion of the IA phase of a website project. 

When I asked, if not wireframes and protoypes, what do you do? He said: just a word document with an outline (for structure) and the actual designs rather than wireframes. I agree that collaborative prototyping makes sense, but I really feel strongly that the wireframe/prototype stage saves a lot of misery  later in the proejct.

I'd love to hear from you all: have you had similar discussions? If so, how have you handled them? 

(((Pl
3 Aug 2010 - 12:37pm
benjordan
2009

Difficult discussions.  I have had the same discussions with both programmers and creative directors/designers.  I think it's difficult for a lot of designers to think about doing design in iterations, they want the Picasso, so it's hard for them to let go of that.  They think of it as their precious.  :)   I emphasized the communication that is enabled and the increase in trust when everyone gets visibility into the process.  I think the psuedocode explanation is a great one that developers can relate to.

By way of advice, if you want it.  I would review for your own information why is it important to do wireframes/prototypes, and then maybe try to have that discussion with both of those people.  What it comes down to in the end is money.  Solving some problems early on costs a lot less money than spending tons of time designing in photoshop and then coding it up and deciding you have gone down the wrong road.  This doesn't mean you have to spend lots of time on it, but it will save you money in the end 9/10 times.  If you're in business then that is important, to the people running the show especially, although they don't always understand that.  :)

Here are some links that might help.  Good luck!
http://www.45royale.com/blog/articles/the-importance-of-wireframing/
http://www.boxesandarrows.com/view/integrating
http://www.adaptivepath.com/ideas/essays/archives/000863.php

3 Aug 2010 - 1:08pm
kbeardsley
2010

WOW. How sad. We are hiring, and we love people with wireframe experience. Please contact me!!!

3 Aug 2010 - 1:09pm
Lee Andrese
2010

Someone who attended the UIE Web App Masters Tour in Philly, please correct me if I misinterpreted the following. I believe it was Jason Fried from 37Signals that said that they go right to design, bypassing documentation.
The necessity for detailed documentation may depend on the size and sophistication of the organization, team, management and complexity of the project. For 37Signals limited documentation, if any, seemed to work. Meanwhile, others in the room cringed.

Until you can show business impact, it will be hard to get buy in. What happens to the quality of the product and cost of development when documentation is skipped?

4 Aug 2010 - 2:06am
Gray Holland
2010

No one has time to do it right the first time, but everyone seems time to do it twice... I'm sorry you are having the most classic battle between the creative part of the process (design) and the execution (engineering). The issue is that you are from different worlds. The best case is when these two worlds think of themselves as interdisciplinary, and have respect and appreciation for all. This is possible, but take complete support from management.

Don't spend much time convincing, in the end it is your job to design as you see best. You wanting to bring them alone might be impossible so don't invest too much effort into it.. You need to do your job the way you see best.

Gray

> via iPhone

On Aug 3, 2010, at 18:01, Nancy Roberts wrote:

> I had a disheartening discussion with a programmer at our office yesterday. He felt that we should not "waste our time" with prototypes, or even wireframes! He said that our creative director found the wireframes limiting, and ended up giving back to us exactly the layout that was provided in the wireframes. I explained that the process of wireframing and prototyping helps work out the flow of content, the page requirements, online interactions, and serves as a guide for design. And I said that many designers I'd worked with had been able to interpret the wireframes just fine. But in essence he was saying skip a good portion of the IA phase of a website project. > > When I asked, if not wireframes and protoypes, what do you do? He said: just a word document with an outline (for structure) and the actual designs rather than wireframes. I agree that collaborative prototyping makes sense, but I really feel strongly that the wireframe/prototype stage saves a lot of misery later in the proejct. > > I'd love to hear from you all: have you had similar discussions? If so, how have you handled them? > >

4 Aug 2010 - 7:39am
Nancy Roberts
2008

I've tried to be really careful to position wireframes as a kind of shorthand for the page elements/content. (I'll say, we know that we will have a main navigational element , represented here, that will contain these six items. It may actually appear anywhere on the page, and that will depend upon the design.)

Also, I use Axure to create my wireframes and prototypes, as it does output both a clickable (HTML) "website" as well as a specification document. 

I use this primarily to a) work through the structure and content, b) work through any interactivity, and c) share this information with the client early enough that we can iron out as many problems/issues as possible before we start to code.

For the programmers, I have been creating a spreadsheet that lists (hierarchically) the site structure, assigning a template to each page, and detailing any functionality or special requirements for that page (such as, this page is dynamic and populated from ABC database). 

I also like to use the prototype to test for usability issues.

4 Aug 2010 - 7:41am
smitty777
2010

I think its essential to let your work speak for itself.  I've introduced wireframing into the business process in a number of companies.  There has always been some level of resistance, but the difference between the projects of the "adapters" vs the "traditionalists" is striking.  But upper management is pretty quick to notice that the projects that incorporate wireframes into the process go much more smoothly and have better, robust results.

Think about it- what is the actual purpose of the wireframe? It's not really to specify the actual design (I know I'm going to get some disagreement here), but it's to get agreement on the specification of the actual design.  That is, the wireframes actually become an agreed upon requrements document, and the main benefit  becomes the aligning of the stakeholder's expectations.  Instead of working from multiple sets of visual requiements, the entire project team is forced to work from the same page.  This also means that it's a living, shared document which is owned by the team (which is hard for some IAs).  

5 Aug 2010 - 9:59pm
Nancy Roberts
2008

Smitty777... very well said. "To get agreement on the specification of the actual design." That articulates it perfectly.

For me, as the IA and usability advocate, it's also a means of testing the story and functionality. I also frequently end up as content strategist, and the prototype helps me discover content holes and weaknesses, and opportunities for us to show rather than tell. 

For our clients, (and to their credit most of them can get past the "is that really what it's going to look like?" issue), wireframes and prototype help them "see" the 3 dimensional nature of website content. Many of their issues arise, properly, during this architecting phase of the process. We discover and refine requirements as we work through the wireframing and prototyping with the client. 

For the designers I work with who don't find them limiting, the wireframe is exactly as you put it: a specification for their design.

I had a very happy moment yesterday. We've just completed the initial architecture of a new site, and we've done some early concepting. I asked if we could get some paper comps. The designer asked me where my wireframes were! 

He likes them! He really likes them!

I will be a totally happy IA when that designer and I can have worked through the wireframes together.

6 Aug 2010 - 11:59am
smitty777
2010

It is interesting - it's so easy to view the wireframes as a visual spec instead of an interaction design document, which they should mostly be. For the orignal poster, I would have her ask the developers how they expect to make decisions on all the 100s of behavioral decisions in the design.  After code?  We all know how that goes.  Much cheaper to wireframe.

I just gave an inservice on wireframing yesterday (...yes, this thread was perfect timing), and one of the things we talked about was user expectations vs. fidelity.  It's interesting to me that many w/f programs utilize "hand drawn" widgets as a feature.  I think this is done to really drive home the point that "this is not the look and feel, and you're only supposed to look at a specific aspect of the UI". 

Congrats on your happy moment.  Sounds like they're starting to come around - that's defintiely the first reaction you want.  I had a similar experience.   A program manager wanted to have a meeting with the stakeholders, but neglected to inform me that she wanted wires for it.  When I showed up empty handed, she said "what are we going to talk about now?".   It was awesome! - they had become ingrained on using the w/fs to drive the conversation. 

 

6 Aug 2010 - 11:59am
smitty777
2010

It is interesting - it's so easy to view the wireframes as a visual spec instead of an interaction design document, which they should mostly be. For the orignal poster, I would have her ask the developers how they expect to make decisions on all the 100s of behavioral decisions in the design.  After code?  We all know how that goes.  Much cheaper to wireframe.

I just gave an inservice on wireframing yesterday (...yes, this thread was perfect timing), and one of the things we talked about was user expectations vs. fidelity.  It's interesting to me that many w/f programs utilize "hand drawn" widgets as a feature.  I think this is done to really drive home the point that "this is not the look and feel, and you're only supposed to look at a specific aspect of the UI". 

Congrats on your happy moment.  Sounds like they're starting to come around - that's defintiely the first reaction you want.  I had a similar experience.   A program manager wanted to have a meeting with the stakeholders, but neglected to inform me that she wanted wires for it.  When I showed up empty handed, she said "what are we going to talk about now?".   It was awesome! - they had become ingrained on using the w/fs to drive the conversation. 

 

6 Aug 2010 - 12:07pm
smitty777
2010

>>For me, as the IA and usability advocate, it's also a means of testing the story and functionality. I also frequently end up as content strategist, and the prototype helps me discover content holes and weaknesses, and opportunities for us to show rather than tell. 

I think you hit the nail on the head - most folks tend to focus on the visual aspect of the wires, rather than the functionality.  But that's the real beauty of the w/f - looking for the holes and weaknesses, as you said.  And that's really the hard part of our work, isn't it?  Not only do you identify them, you also are able to get consensus on the solutions from all the stakeholders (the other hard part of our job :^)

It is interesting - it's so easy to view the wireframes as a visual spec instead of an interaction design document, which they should be,mostly . For the orignal poster, I would have her ask the developers how they expect to make decisions on all the 100s of behavioral decisions in the design.  After code?  We all know how that goes.  Much cheaper to wireframe.

I just gave an inservice on wireframing yesterday (...yes, this thread was perfect timing), and one of the things we talked about was user expectations vs. fidelity.  It's interesting to me that many w/f programs utilize "hand drawn" widgets as a feature.  I think this is done to really drive home the point that "this is not the look and feel, and you're only supposed to look at a specific aspect of the UI". 

Congrats on your happy moment.  Sounds like they're starting to come around - that's defintiely the first reaction you want.  I had a similar experience.   A program manager wanted to have a meeting with the stakeholders, but neglected to inform me that she wanted wires for it.  When I showed up empty handed, she said "what are we going to talk about now?".   It was awesome! - they had become ingrained on using the w/fs to drive the conversation. 

 

13 Aug 2010 - 7:11pm
Dave Malouf
2005
If yup are only using wireframes and prototypes to communicate design decisions to the team then I feel you are missing a major purpose of these tools. They are for design! They are artifacts for reflection & refinement & most of all experimentation. Explore, validate, refine, repeat. The total team should be engaged in this process so they not only align, but contribute their POVs & required expertise. If you are just handing off artifacts made in a black box someone will a,ways a) misinterpret b) find fault & use it as an excuse to delegitimize you - Dave
24 Aug 2010 - 2:43am
Florian Fiechter
2010

I was dealing with this a lot. In meanwhile I could show that low-fi prototypes helps even developers.
Stakeholders usually have crazy ideas about features and solutions until they see the end solution.

As Steve Jobs already said; A lot of times, people don’t know what they want until you show it to them.

Developers can be realy annoyed by re-programming things over and over again because stakeholder
do not exactly know what they want. That costs not only nervs, but also time and money.

In low-fi prototypes I usually can find problems and design a solution that works from beginning.

22 Nov 2010 - 10:17am
holger_maassen
2010

Interesting discussion and it's again and again just the same.

A problem that we have to encounter again and again in our practice.  Perhaps this article might be interesting for the one or other:

http://ux4dotcom.blogspot.com/2010/01/why-and-why-not-wireframing.html

Within the interactive media branch it is as important as in the classic offline media  to clearly define the goals and the scope of duties - And to define the processes and project steps / milestones. Processes are often not defined, impractical or ambiguous.

Maybe this article could be useful, helpful:

http://boxesandarrows.com/view/ux-design-planning

 

 

22 Nov 2010 - 11:24am
Nancy Roberts
2008

Your comments and articles led me to an interesting insight: I think one of the problems is that many of the websites we design are inherently NOT "interactive." Yes, they allow people to click around gather information, but the activity has more in common with paging through a brochure or annual report.

Our company approaches most of its "web" design as a tv commercial on steroids - it's all one-way communication; the objective is to get people to "get interested" in a product or service, possibly send an email or request an appointment. Our emphasis is all on display and style, very little on browsing patterns or click analysis or A/B testing. We spend heaps of time on a flash banner that "tells a story" (note TELLS), and very little on thinking through how people are likely to use a site, and even less on assessing how they do use it once its available.

We talk a good game about analytics, but we don't go back and try another button, or different wording. We "refresh" our sites and encourage new content, but don't really treat them as a thing to be "used," more a thing to be "viewed."

22 Nov 2010 - 1:05pm
Rhonda Ranney
2010

Nancy,

Exactly. When I developed the eLearning modules, there HAD to be interaction on every page, otherwise the end user was just" reading". From and Instructional Design perspective, I had to provide the end user various options to meet his/her learning style. As well as give them choices to exit at certain points, take quizes etc...

My point is, that type of design required heavy wireframing and story boarding. However, MY wireframe audiance was internal and I needed to create wireframes that were applicable for my team. Yes the person taking the module was the ultimate end user, however my team, in an essence was the end user of my wireframes (the crutch of the design process). Working with so many counterparts in "big corporate" , IT, Customer Service, Sales , Training etc...it helped to be strategically flexible, without compromising the creative process.

The level of detail, wireframe format etc. always depends on the project, level of interaction, as well as its complexity. Though, that IA piece is always crucial.

Rhonda :)

On Nov 22, 2010 12:06 PM, "Nancy Roberts" <nancyc.roberts@gmail.com> wrote:
> Your comments and articles led me to an interesting insight: I think one of
> the problems is that many of the websites we design are inherently NOT
> "interactive." Yes, they allow people to click around gather information, but
> the activity has more in common with paging through a brochure or annual
> report.
>
> Our company approaches most of its "web" design as a tv commercial on
> steroids - it's all one-way communication; the objective is to get people to
> "get interested" in a product or service, possibly send an email or request
> an appointment. Our emphasis is all on display and style, very little on
> browsing patterns or click analysis or A/B testing. We spend heaps of time on
> a flash banner that "tells a story" (note TELLS), and very little on thinking
> through how people are likely to use a site, and even less on assessing how
> they do use it once its available.
>
> We talk a good game about analytics, but we don't go back and try another
> button, or different wording. We "refresh" our sites and encourage new
> content, but don't really treat them as a thing to be "used," more a thing to
> be "viewed."
>
>

Syndicate content Get the feed