APPROACH

My approach varies from client to client, but follows this basic outline that works for small projects like a fast tradeshow demo, or comprehensive redesigns of complex mature products. It starts by gathering information about users and the technology, synthesizing a design, and then subjecting it to review. Finally, I provide the code, tools, and other resources you need to deliver the finished product.

1. Listen to Users

First, I need to understand who is using the software. Ideally, this means visiting them in their own workplace, asking questions, listening, and noticing what's written on the Post-It notes stuck to the monitor. This has gotten me into classrooms, busy warehouses, and an operating room! If you're searching for a market, it's often useful to develop personas or a scenario that details your customer's background and motivation for using your product. As an interface designer, it's important to me to develop sympathy for your customers in a way that isn't possible through a typical feature requirements document.

2. Learn the Technology

Only after learning about the users, I focus on the technology. This means learning about your existing products and the technology you are planning to use. I prefer to do this after talking to users because even though I need to design something that's possible to build, I don't want to be influenced too early on by what's convenient for the developers.

3. Create a Model

The third step is creating a model, synthesizing the technology and your users' needs. The visible result of this step depends on what kind of interface we're building. For a web-based application, I develop static HTML pages that look just like the finished product. For a desktop or PDA application, you'll see pixel-accurate screenshots. For a voice recognition application, I turn over audio files or scripts depicting typical phone calls. This step also results in less visible models, implying the model your users will form mentally while using the product, and also the programming model your engineers will use to build it. In any case, this is an exciting phase for everybody, filled with anticipation.

4. Educe Feedback

Presenting polished mock-ups to you and your customers is the best way to find out if a design is on the right track. I have found that even among engineers, it's hard to see how a product will work just from reading a spec. Sometimes the models from step three will be changed and this step repeated, but often a few notes on the changes is enough before moving on to the next step. This is the exciting part that makes ideas real.

5. Build the Prototype

Once the model is approved, I begin coding the user interface, generally a prototype that covers every interaction without manipulating actual data. Your users and team have something with tires to kick, and your engineers have a useful artifact. When the UI makes use of speech recognition or another new technology, this gets the engineering team up to speed on the new stuff. Even if it's a familiar desktop GUI, the prototype of the user interface defines a programming interface (API) to the rest of the system, ensuring that the system architecture accommodates your user's needs. Too often users are forced to navigate through limitations of a system architecture that was put in place before users were considered. Since I do the work myself, you can be assured that the user interface is exactly what the designer intended.

6. Deliver Results

Delivery ranges from something as simple as e-mailing code, media assets, and documentation to conducting demos and formal and one-on-one training. What I do for you depends on how quickly your development staff grows and what their specialties and preferences are. Some clients like to bring everything in-house as soon as possible, and others like to take advantage of my independent perspective as the product evolves.

My specialty is the early phases of product development, but I remain available to review the product as it progresses. It's particularly gratifying to watch a solid design survive new uses of the product, updates to the operating system, and several versions of improvements by generations of teams I never met.

Home Articles Site Map Links Contact
Last updated by Brian Krause, brk@adducive.com, August 1, 2005
Adducive 1 650-274-2415 (+1 650-BRIA-415)