Comments on: Blinded by the user interface

By: Rob W

Rob W — Fri, 23 Mar 2007 15:52:00 +0000

Rafa -
The UI prototype should be as ugly as possible? I don’t think that would work. If you’re at the stage where you’re scribbling on a whiteboard, that’s fine (i.e., you won’t *make* it ugly, but people won’t get hung up on the fonts and so on).

But once you are showing them a UI, they *will* focus on that. They will have trouble getting past the green/orange buttons, because they want to be sure the final application looks professional. Your really ugly mockup will just make them think you aren’t a good developer, unfortunately.

Basically, I tend to design initial navigation & layout based on research into their existing workflow and requirements, interviewing people *without* a real UI first (then only whiteboard drawings). Once I show them a UI, it will look good if at all possible, and we’ll go back to walking them through the use cases to tweak them and flush out more requirements.

Telling them not to focus on the UI simply doesn’t work — once it’s there, it’s by far the most tangible aspect of the application, and they’ll want to talk about it. (That, and somehow input validation and field sizes seem to take inordinately high priority…).

I agree that a “finished” looking UI will require you to adjust their expectations somewhat — you’ll have to spend some time going over the effort remaining, time estimates, etc. — but this is far easier than spending 2 hours talking about the buttons.

By: Rafa

Rafa — Tue, 13 Mar 2007 11:32:16 +0000

A guest lecturer one said: the UI prototype should be as ugly as possible. Make it look ugly. The worst you are drawing, the better. Why? because then people focus on things like where things should be, and if the navigation makes sense, instead of discussing for one hour if the button on the left should be blue or green, or maybe orange. When you show nice UI interfaces that look finished, people would focus on small, uninmportant (at this stage) details, and even worse, they will think that it’s almost finished (looks finished, right?) so they will expect to have it up and running in a few hours.

By: Ernie Josefik

Ernie Josefik — Mon, 12 Feb 2007 00:14:00 +0000

As someone who has spent 18 years integrating Geographic Information Systems with business systems I can totally relate to your experience. One of my favourite memories however is of trying to rush through a 30 minute software presentation in five minutes because the client was late for another meeting. As he was getting up to leave I quickly brought up the unfinished splash screen to confirm the size and position of the logo. An hour later we were still sitting together modifying and perfecting this screen.

The arguments for and against prototyping screens early have been around for ever. Although I have always been a fan of the practise I have found it can also backfire because they focus everybody on screen design rather than required functionality. I still recommend UI prototyping however only after the required functionality has been established with Fit/FitNesse.

By: Lucas Goodwin

Lucas Goodwin — Mon, 05 Feb 2007 20:14:45 +0000

When developing our internal applications I always prototype the UI first. Once I have sign-off on the presented “functionality” I make it work. This is in part because our specs from project managers/proposers are typically nothing more then a few paragraphs and of no help. Regardless, I’ve found the process a very efficient way of determining what the users actually need before wasting time writing functionality they’ll never use.

By: Mr Angry

Mr Angry — Fri, 02 Feb 2007 05:19:00 +0000

Just don’t go too far the wrong way. I’ve been in situations where people wanted to overdevelop the UI to the point where it would have been severely intrusive. People would not have been able to complete everyday tasks without enduring a series of flashing lights and animations. The look may well be what sells a product at first but the results are what makes a customer happy at the end of the day.