Unit of 1 - User Interface Should Be a Team Effort

eferlazzo writes "In my previous 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?

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 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.

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!

***********
Ellen Ferlazzo

Designer / Writer

www.sprez.com"

Main Menu

Who's Online

User Interface Should Be a Team Effort

Related Links

Article Rating

Options