Prototype nightmare

September 10, 2006 10:27 AM

[SoftwareEngineeringFilter] As an application developer, how do I convince my business users that they don't NEED to see screenshots or a prototype in my design documentation? [more inside]

I'd like some feedback from both sides of the fence (developers and business analyst / business users).

I am on the second release of a small web application with about 8-9 screens in it. In the initial release, we put together a prototype and from that prototype took screenshots that were put into our design documentation.

Our design documentation is the be-all, end-all contract between ourselves and our business users as well as our testers. As a result it has to be 100% accurate (although in reality it never is).

Additionally in the first release of this application, we went through 8 "walkthroughs" with various stakeholders and each time, a reasonably high up executive would comb over the document and focus on the screenshots picking out small label changes here and there without validating any of the business logic or that we had covered off all the requirements.

So instead of getting a lot of development done, I went through too many iterations to count of updating the document to fix things like "oh, we don't like that red text", or "can you relabel this to ...." or "can you move this up and this down.."

I want to avoid this situation as much as possible with this second release but I have little management support from my development manager. He is of the mind that prototypes and screenshots add a huge value to the business and we should continue to do them.

The business even went so far as to take our prototype and use it to tour across the country with it to highlight how the application would be used prior to the application being launched. This led to EVEN MORE work on the prototype. In the end, this prototype ended up matching the production application 100%.

I really want to avoid all these problems and not eat up a lot of time in prototyping/screenshotting and have business users focus on the requirements they had set forth and to validate that the developers' understanding of the requirements is correct. How do I do this while keeping all my stakeholders happy?

posted by PWA_BadBoy to computers & internet (22 answers total)

A lot of people are visual - screenshots and such tend to help understanding tremendously.

That said, the rougher they are, the less likely people are to nitpick specific details of the implementation. So for small applications like the ones you're suggesting, rather than prototyping, consider just drawing (whatever illustration tools come with your word processor) simplified representations of the pages - the sort of stuff you might draw on a white board, but neatened up for public viewing. Focus on data flow in diagrams, and add specific details of fields in lists on the same page as the diagrams.

Be prepared though, that if they aren't tweaking labels and colours at this early stage, they're going to want to tweak them much closer to production, so build in a step somewhere along the way to bring back more finalized prototypes for that level of disection.
posted by jacquilynne at 10:34 AM on September 10, 2006

Visual thinkers want to see something visual. When I'm dealing with a 'high level executive', 99% of which tend to be visual thinkers for whatever reason, I almost always flowchart the business logic using a package like Visio or OmniGraffle. I present them with several large 11x17 sheets detailing the business logic first, and tell them that the interface design depends on the business logic being correct for both wording and process. If the process isn't correct, the 'flow' of the application's design will be broken and the software won't create the maximum value that it can create.

Only AFTER they've validated the business logic do I do interface mockups, and only if they ask for them. If they ask for them, I usually say that we deliver those along with test builds of the application. At that point, it's OK for them to nitpick labels. I also usually have the senior level guys verify the business logic AND have their secretary/admin/staffer/slaves verify the business logic as well.

But you absolutely must present them with a 'picture', and they always will look at the picture as opposed to stepping through the written logic.

(3 years of consulting here, 2 of it running my own company. I now work for a major university doing the same thing I was doing as a consultant, albiet with a steady paycheck... and I do consulting on the side.)
posted by SpecialK at 10:34 AM on September 10, 2006

Hey guys. Great answers so far. I fully agree with the label part. I just don't want to be tweaking a prototype for labels when I could be tweaking production code for the same thing. It's a matter of not duplicating work for myself and doing what makes sense.
posted by PWA_BadBoy at 10:37 AM on September 10, 2006

A prototype should be a proof-of-concept. It lets you tackle any possibly difficult parts of your application early and mitigate any risk involved. A prototype should be disposable, something you throw away. It should never reach the level of the real application.
posted by utsutsu at 10:39 AM on September 10, 2006

Are your projects normally fixed cost, quoted, or free-for-all billable hours?

If it is fixed cost or quoted then you really need to nail down how many "prototypes w/ screenshots" you will show your customer for them to criticize. When it comes down to it, most customers don't know WHAT they want, they just know that they need something in place soon. Whenever you show them a prototype it gives them an opportunity to redefine the requirements. I say every time your customer redefines or appends the requirements you give them a new quote. If it is fixed cost then you cannot exceed the amount. Quotes give you more flexibility.

If it is all just billable hours, then I'd send them a prototype with screenshots as often as possible. As long as after each iteration this way they realize that their changes to your design will add more hours to the project and their bill will grow, then who cares? Keep on working on the project until they are 100% satisfied and then bill for your time accordingly. Some customers will prefer it this way and are willing to pay big bucks for something like this.
posted by nickerbocker at 10:58 AM on September 10, 2006

I'd never send screenshots. Draw them pictures. Too often, if you include actual screenshots they either:
1) Accept them as the finished product, even if it's not what they want. Drawings are easier to say "actually, what I wanted was..."
2) Or they think that most of the work is already done, and they don't value all the time you spend AFTER the screenshots to make it actually work.
posted by blue_beetle at 11:03 AM on September 10, 2006

He is of the mind that prototypes and screenshots add a huge value to the business


Your manager is probably right. The prototypes give them something concrete they can touch and feel and see. I would never try to do business analysis without it.

That said, someone other than the application developer should be doing this work. If were you, I would try to make a case to your manager that it would cost considerably less for a business analyst/UI designer to be doing this work and to let you focus on what you do best.

In seven years of consulting, the most successful projects I've been on have been the ones where a prototype was done and the screens matched virtually 100% to the production application. This responsibility falls to the business analysts and UI designers (I am usually involved just to provide architectural input - is it technically feasible to do what they want to do). The developers are left to implement the design.

If your business users are not involved in the application design, there is a high likelihood of project failure. Not necessarily because the application is not useful, but because they feel they weren't part of the process.

(Of course, this only works in an environment where you have business analysts/designers on staff - your mileage may vary)
posted by jknecht at 11:06 AM on September 10, 2006

As someone who spent many years in web development management, here's my advice: All that visual tweaking actually is valuable to the business much of the time. It can be a drain on time you'd rather spend getting functional specs nailed down, but it's work that will have to be done eventually. The way you fix this with web applications is to divorce the business code as far as possible from the UI: treat them as separate work products, with separate requirements documentation, and arrange your contacts with the business folk around coping with the "front end" and "back end."

Rather than prototyping-to-production, you should wind up with nearly-usable front end code crafted in partnership with the business that can sit on top of the business code. Your business folk get to have their two cent input to the UI, get a work product that's valuable to them for the road shows and such, and you get to leverage all that effort spent in UI-fiddling meetings towards shipping final code.

Of course, that means you have twice as many meetings, because you have to work on functional requirements separately.
posted by majick at 11:13 AM on September 10, 2006

If you choose to go the "draw them pictures" route, you may consider using DENIM for your drawing. It is a quick way to do the prototype while remaining (hopefully) crystal clear that it isn't going to be a faithful graphical representation of the final product.
posted by Mr Stickfigure at 11:21 AM on September 10, 2006

If possible, produce a plain, unstyled prototype; just black text on white, with grey boxes grouping things. That avoids premature discussion of graphic design, focussing attention on the fundamental UI issues (it also makes changes easier).

In parallel, general design and branding issues should be considered, but personally I think it's a mistake to do actual page design and UI layout at the same time and you should schedule more time and charge more if this is needed.

(Some clients actually like clicking around a plain interactive prototype if it's explained properly, it makes them feel like they're getting more of an insight into the development process.)
posted by malevolent at 1:23 PM on September 10, 2006

Nthing what everyone else is saying: we always use plain black and white diagrams, not screenshots. And the person who handles the diagrams and any questions about them is not a programmer. It's a specific position dedicated to Information Design.
posted by AmbroseChapel at 1:50 PM on September 10, 2006

In my experience some people can't even wrap their heads around what you are talking about until they see a prototype, but if you're concerned, I would break the delivery process into two stages. First map out your requirements and get sign off on those, and then create your prototype. Have meetings to walkthrough the business rules just as you would to walk through the prototype. There will be a lot of changes during the prototype walkthroughs, but more will be correct from the get go, especially the underlying aspects of the design that much of the time are completely ignored when everyone is focused on the prototype.
posted by xammerboy at 2:08 PM on September 10, 2006

I think in the end, you just need to convince managment that the nitpicking and tweaking of things is a step that should come after prototyping and not during. That said, like others I agree some people are very visual and need to see something...even if it is just an illustration. If you go the illustration route, I think that there will be less tweaking to do as you can just say "it's a representation of what the final product might look like...it's just an illustration...so tweaking of this will come later in the process. For now, I'd like to highlight the functional requirement...if you'd turn to page..."
posted by crypticgeek at 2:10 PM on September 10, 2006

I was part of a similar process for a web application for a bank eariler this year, so it was fairly large and some parts may not apply.
The approach we took was having a UI designer, a SME (or 2) and BA sit down and work through the business cases together developing the screens in axure. We had one usability person that would check the screens for consistency across existing apps, inhouse style, branding, etc.
We would then create the HTML screens to match the axure document and formally review all those screens from business cases in sections (say business cases 1 to 6), in the review there would be the UI designer, SME, BA, Usability person and lead BA. This really helped as you noticed screen inconsistencies, functionality that got missed, etc.
At any point if we were unsure that what we were proposing was not techinically possible we'd call in the lead developer. Once the business signed off the screens we'd then pass the HTML files over to the developers.
posted by X-00 at 2:35 PM on September 10, 2006

Wireframes are the appropriate compromise to handle this exact problem. One resource that I found indispensable in organizing this entire process in my head (including which deliverables should be created at each stage in the process) was Jesse James Garrett's Elements of User Experience, which you can get a good feel for from the PDF which first outlined the ideas.
posted by anildash at 3:12 PM on September 10, 2006

I agree that you can't avoid illustrations of some sort. I write end-user and developer documentation, not design documents, but I am always getting called upon to put more diagrams and screen captures in. I always skip over illustrations when reading, so I instinctively consider them wasted space and seek to minimize them. I have to fight this tendency, because apparently a lot of people really appreciate having things laid out visually. Go figure. Anyway, these people exist and you can't kill them, so you have to give them something. It should be as rough as possible to make it clear that the appearance is not the current focus. Make it intentionally look ugly.

Now in the situation you describe, my advice would be not to create additional prototypes based on the nit-picky feedback you're getting. Instead, be crystal clear up front that they are NOT to nitpick the appearance during the initial iteration, but rather evaluate the business logic and judge whether the proposed interface meets the requirements, and keep sending the original prototypes back until you get the feedback you actually need. Make it very clear that wording and graphics and even other aspects of appearance are relatively easy to change and can be continuously tweaked right up to release, but that workflow is very difficult and expensive to change and therefore must be nailed down before serious development starts. Run your meeting -- that is, take charge of it and enforce these rules and do not defer to the bigwigs on these issues. (Chances are excellent that they will respect you for this. If not, it's a good sign that you will not be happy working there.) If they don't have any substantive feedback, reschedule the meeting and ask them to come prepared next time.

The reason people are critiquing the labels rather than the higher-level issues is because they're busy, and critiquing how something looks is much easier to fit into their day than critiquing how it works. To critique how it looks all they need is what in front of them; to critique how it works they must hold the entire application (or at least a whole process) in their head. This is the charitable way to say it. The uncharitable way is to say that they are lazy or incompetent -- or simply incapable of understanding what you are trying to accomplish.

The nice thing is that if you can get them to go along with you a time or two, and you produce good results, and they are reasonably smart, you will earn their trust and respect. Not only will they then go along with you eagerly, they will probably start giving you freer rein. "I'm sure you've thought of everything, I'll just give this a quick glance and rubber-stamp it." But then you have to make sure you really have thought of everything, or else it'll be your fault if the project fails.

Another option of course is to switch to some kind of agile process that embraces chaos and allows requirements to evolve in a less structured way, but that would probably freak them out even more.
posted by kindall at 5:07 PM on September 10, 2006

The first two answers are terrible. Executives aren't "visual thinkers". They're people who don't understand what the hell you're doing, so they concentrate on - tweak - the trivial things, like text color.

It works the same way with a written document - you send off a 50 page document for comments, you won't get a single comment about the gist of the document, where you're going with it, the main goals, none of that. What you'll get back is feedback like "I don't like the phrase "business case" - I think we should use "business scenario"." And when you change it and send it back, the *very same person* will send you feedback like "I don't like the phrase "business scenario" - we should use "business case"."

Lather, rinse, repeat. The driving forces are this:

1) In order to look like they're earning their paycheck, everyone you send [thing] to for feedback wants to provide feedback.

2) Most of them don't understand it.

3) It takes time to give real feedback.

4) Accordingly, you get lame feedback about punctuation and text color, and zero feedback about real issues.

Some of the later commenters above have hit upon the appropriate solutions - black-and-white prototypes, wireframes, whatever. Anything to eliminate the ability of reviewers to nitpick the nonessentials. You must also avoid, whenever possible, getting any feedback at all from people who really aren't concerned with your project or don't know what you're doing. Their feedback is worse than useless - it actively hurts the project.
posted by jellicle at 5:20 PM on September 10, 2006

The first two answers are terrible. Executives aren't "visual thinkers". They're people who don't understand what the hell you're doing, so they concentrate on - tweak - the trivial things, like text color.

Umm, gee, thanks. Yeah, I guess all my years as a BA are wasted, since apparently I have no idea what I'm talking about.

I didn't say executives nitpick the visuals because they're visual. I said visuals are mandatory because a lot of people are visual. Even some of the people who will know what they're talking about will still require visuals to know what you're talking about.

I then went on to suggest almost exactly what you did - visuals that are rougher than finished, diagrams and generalized pictures that focus on workflow instead of screenshots so that people can't nitpick colours, because the colours obviously aren't final.
posted by jacquilynne at 6:21 PM on September 10, 2006

Wireframes or gray-screens are exactly what you need. Clients can object to certain pieces of information being shown or not, but the lack of actual visual design means a lack of footholds for bikeshedding.

Trying to keep people from nitpicking a prototype is impossible, so the less opportunity you provide for that, the more you can focus your clients on what matters. When you tell someone not to critique something they're paying you to do, you're sending all sorts of weird signals to your client, none of which you intend.

For the long story on this, read this e-book.
posted by Coda at 6:55 PM on September 10, 2006

What you want is to have the reviewers focused on the business logic that you mentioned. Can you present that visually somehow? Make it _more_ eye-catching than the gray screen/wireframe mockups? It doesn't have to encapsulate everything, just to draw the reader's attention enough to get them to read the correct section of the document. Then, perhaps, they'll focus on that.

Also, maybe include a short paragraph on "how to review this document" that might help them understand how to help you. Something like "Please make comments on any errors we have in section _________."

Yes, I realize that a lot of people will just go to the prototype pictures anyway, but perhaps if you also emphasize this point verbally -- or at the top of an e-mail -- when giving out the document (and get whoever presents the document to do the same thing), and if you make the mock-ups look less fun, and make some kind of cool entity diagram to represent the business logic, you might have a fighting chance. Especially if the logic diagram is beautifully illustrated in color _and_ if you encourage them to nitpick the actual choice of words there.

It may be too late to "un-spoil" the client on this project, but these ideas may help with future projects. Making sure you get valid feedback on the requirements/basis of the project is important for letting your team think creatively in working on the actual product; you're right in that spending too much time tweaking a prototype is a time-eating distraction, but more than that, these changes are (it sounds like) being made without the informed design process that will lead to a better end result -- and then those changes are naturally being incorporated into the final product, since they are what the client thinks they want. There might be a better solution, but this "process" won't let you work toward finding it.

Good luck.
posted by amtho at 4:54 AM on September 11, 2006

(Oops, looks like lots of these points were covered by amtho above ... oh well.)

I'm with the other people in this thread who suggested going with lower detail mockups. That's definitely worked for me in the past.

I've also found that this kind of interaction with people is something that is a skill both for you and for them. You need to get used to being clear about exactly what level of feedback you're looking for. Appropriate visuals helps with this, but what you say along with them is also significant.

On the flip side, the people you're working with need to get better at focusing on the right issues. I think some of the other comments are a little too fatalistic about management people being hopelessly myopic in design reviews. I suspect they would like to get better at it, and you can help them. Kind reminders (as appropriate) about what kind of feedback is helpful for you at this stage can make a big difference in the long term.
posted by heresiarch at 6:33 AM on September 11, 2006

You might also want to look into some standard development methodologies. I've worked both sides from FuncSpec/Prototyping as well as Agile shops. There are others such as Scrum which offer similar ideas.

The main concept is to break down the project into smaller sub projects which you can develop quicker and get immediate feedback from the end-user/stakeholders.

For example, if you're making a user registration piece that collects several bits of information (like myspace). Develop one piece at a time (like address input screen) and deliver that quickly and get immediate feedback. Then add onto it with your next iterations (like music preferences, movie preferences, etc...). You'll be building better software because your QA/User acceptance will happen DURING the development process instead of the 3-4 weeks at the end. It works.
posted by kookywon at 2:16 PM on September 11, 2006