Software Reality
Programming with
a dose of satire.

Site Map Search


Agile Development
 
Extreme Programming
 
Code Generation


Articles
Lifecycle
Design
Programming
Soapbox
Reviews
Cthulhu

Check out our ageing Reviews Section


Use Case Driven
Use Case Driven Object Modeling with UML: Theory and Practice
Get from use cases to working, maintainable source code. Examples use Spring Framework, JUnit and Enterprise Architect

Agile UML
Agile Development with ICONIX Process
A practical subset of agile development techniques, illustrated by example

Get Controversial!
Extreme Programming Refactored
Extreme Programming with a dose of satire
Available now:



ICONIX/Sparx Public Classes to Come to London

ICONIX is planning a series of open- enrollment public classes entitled Hands-On Enterprise Architect for Power Users in collaboration with Sparx Systems.




Architecture and Design

User Interface Design Should Be a Team Effort

By Ellen Ferlazzo
June 2, 2002

This article was first published at sprez.com.

"What can you do to stretch your existing resources?"

In my last article I tried to get across the message that doing the wrong things faster, or prettier, or with more options doesn’t help your user. But let’s say you’ve got a clear set of requirements; the users have been defined, the features are associated with user tasks, marketing has done a competitive analysis and everything is good to go. Now what?

You need to make sure those “right things” are designed well. But like everyone else, your budget’s tight these days. What can you do to stretch your existing resources? You have a few programmers that have turned out some decent looking software in the past and so you’re ready to go, right? You can always tweak it later and fix the UI down the road after enough customer complaints. Of course this assumes you make it to version 2 and have the budget to redo the software later.

Consider an alternative. First, good programmers are expensive. Do you really want them spending their time deciding where the buttons should go, what words should be used on the screens, what the error messages should say, and then tweaking and re-tweaking these items? Or do you want them concentrating on creating software that is fast, easy to maintain, and very robust? The programmers can only be pulled in so many directions and some will lose sight of the user while they’re working. What if they had a specification that gave them a visual roadmap and let them concentrate on the hard stuff that, frankly, most programmers enjoy more anyway?

"Most users merely tolerate software; they don't like it"

And what if your users didn’t have to suffer through that first version full of clumsy, awkward dialogs with poorly written error messages? Believe me, your support staff will thank you for well-designed software as well! Most users merely tolerate software; they don’t like it. The best interface is one that the user never notices because they’re too busy getting their jobs done, but most interfaces require the user to think about the computer, about the software, about how the programmer decided to implement something. Well-designed software helps the user and doesn’t frustrate them.

How do you create software like that? First, create a team that is responsible for creating a user interface specification which can then be turned over to the programming team for implementation and the documentation team at the same time so the writers aren’t stuck playing catch-up the week before the release! Ideally, the minimal team consists of a designer, a technical writer, and a programmer. Sometimes a combination designer/writer or designer/programmer might be available and used for smaller projects, but in general, bringing in someone who is in charge of the design but works well with your team is optimal. Design requires a distinct skill set, though many good designers come out of documentation or programming.

The designer and the programmer work together to make sure that what is being designed is reasonable to build. Programmers can offer great guidance on the cost-effectiveness of certain design features or point out problems that might arise later. Sometimes they have great ideas to contribute. Sometimes they scoff at something and say it’s too much work only to delight you later by figuring out a way to deliver the design in a cost effective manner!

"The most difficult things to explain are those that are poorly designed"

The designer and the writer work together to make sure that the user’s tasks can be readily accomplished with the design. The writer can begin documenting the how-to sections with step-by-step directions before one line of code has been written by working with sketches on paper or a whiteboard. Any writer will tell you that the most difficult things to explain are usually those that are poorly designed! Bring the writers in early to ferret out those areas and avoid them. They’ll find the useless extra dialogs, the missing buttons, and they can choose the best words for dialogs and error messages as they write.

By working in an incremental fashion from design to document and back again you will have a cleaner software product that is easier to use. Sometimes the programmer or designer can create a prototype or create the actual screens during this process, depending on the language and platform and how quickly they can be created (and discarded). Beware the prototype that never dies! But often a paper version is just as useful. The paper version can be hand drawn or created using tools like Visio, with the emphasis being on quickness and “proof of concept”. The biggest advantage to paper sketches is that they can be quickly redrawn until the basic flow is worked out. See http://www-106.ibm.com/developerworks/library/us-paper/?dwzone=usability for more information on paper prototyping and usability testing.

There’s still plenty of work to do after this, of course. The documentation created during these early sessions will need lots of fine-tuning. Also, the conceptual pieces, the online help, and the quick starts will need to be written, as well as everything else you normally deliver.

"Hopefully the fine-tuning will be minimal due to the work done beforehand"

There will be fine-tuning of the user interface as the programmers actually build it, but hopefully this will be minimal due to the work done beforehand. And with the documentation used as a specification, it’s easy for the programmers to mark up what they needed to change (and why) and hand it back to documentation, eliminating those last minute GUI changes that documentation never learns about until after the release!

Marketing also benefits by getting a solid view of what’s being developed and can plan accordingly. And who knows? There might even be time to train your technical support department in advance!

Copyright © 2001-2002 Ellen Lawson Ferlazzo


<< Back to Design

<< Back to Software Reality

All trademarks and copyrights on this page are owned by their respective owners.
Stories and articles are owned by the original author.
All the rest Copyright 1998 onwards Matt Stephens. ALL RIGHTS RESERVED.