Usable UIs

For many developers, the most interesting aspect of software development is the opportunity to work with new technologies like Java, .NET and Oracle. To our users, however, a system's most interesting feature is its user interface—its screens, reports and supporting documentation. For many users, the system is the UI, so they expect that system professionals are adept at creating usable ones. Uh-oh.

Usability is the measure of the ease with which people can work with your system. Focus on use and usability first, to turn your system into a better tool. The harder a system is to use, the harder and more expensive it is to learn and to support. Features that are difficult to master lead to requests for changes, increasing future maintenance costs. Conversely, the more usable your system is, the greater value your users are likely to place on it. Compare Apple's iPod against much of its competition—MP3 players all offer similar functionality, but the iPod garners a price premium because of its superior design.

Keeping Your Eyes Open
To develop usable UIs, you need to understand your users' skills, expectations and preferences. This information is never mentioned in a feature list, nor is it found on an index card—you learn it only with months and even years of working closely with your users.

[click for larger image] It's a Gem This prototyping tool provides magnetic UI widgets that you put on a whiteboard and draw around as needed.

Simple observation may be the best way to learn about your users. What people tell you they do and what they actually do in practice can be completely different. When people describe their requirements, they'll often tell you the "official way of doing things." Yet when you watch what they actually do, you discover that they do many things that "everyone knows"—but they've forgotten to tell you about. For example, I once worked on a customer help desk system in which the service representatives officially needed to ask their manager to do certain tasks (typically, expensive things). Because the manager was often busy, experienced service representatives would perform the tasks by logging on with a manager ID. By observing this "understood" behavior in action, we learned that we needed different system flows for junior and senior service representatives.

Observation carries interesting side effects: You discover that each person has his own way of working. Have you ever seen a 1950s movie depicting a caricature of a modern office, where workers move in unison, sitting at row upon row of desks organized in exactly the same manner? If you're like me, this inspires a chuckle, because of the absurdity of expecting an entire office to work in a similar way. So why are many software systems based on homogeneous users? If we want to develop systems that truly meet the needs of our stakeholders, we need to build flexibility into our user interfaces.

Focus groups that collect feedback from people who discuss and/or work with your product are a great way to understand your users. For intraorganizational systems, focus groups can be held fairly simply; you merely need to identify representatives of the various classes of users and schedule one or more working sessions. Developing a system for external use is harder, particularly if it's a brand-new system and you really don't know who the users will be. One of my clients goes so far as to pay the travel expenses for selected customers to participate in a week-long focus group for each major system release. Both its major customers and "major complainers" are invited, so that the company can learn what its customer base wants to do with the system. If you don't know who your users are, the onus is on your product managers to identify marketable product features for your first release.

More Feedback
Some organizations hold usability reviews by user interface experts to identify ways in which a system's UI can be improved. Better still, why not involve the UI experts in the actual design process of your system, or even make them active team members throughout the entire development lifecycle? Not only will they help to develop a usable system, they should also transmit their user interaction and UI design skills to the other developers on the team.

You can also adopt Agile Modeling (AM)'s active stakeholder participation practice, which insists that stakeholders (including direct users) be available to provide information, make decisions, and be actively involved in modeling. Your stakeholders are the business experts, so they're best suited to model what they need. Unfortunately, stakeholders often don't understand complex diagrams, nor do they want to take the time to learn them; you need to adopt inclusive models that use simple tools and simple techniques that stakeholders can easily learn and work with. Several inclusive models help you to explore the system's UI with your end users.

Making Models
Creating models—even if it's a simple sketch, to help you think something through before coding, will dramatically increase your productivity as a developer. Several models are useful to explore user interfaces. A low-fidelity approach is to use a large piece of paper to represent a screen or HTML page, with attached sticky notes representing input/display fields. These abstract prototypes are used to quickly identify UI requirements in a technology-independent manner.

You can also create screen sketches on a whiteboard. Because you can draw anything you want, sketches enable you to communicate your UI design more precisely than do low-fidelity prototypes. However, sketching is less flexible, it's much easier to move sticky notes around than it is to redraw.

User interface-flow diagrams can be drawn to show how users transition between screens and reports. During development these diagrams are used to explore a system's high-level usability, providing a bird's-eye view of your UI's design—you can easily assess whether or not the flow within your UI will support your users effectively. UI flow diagrams can also be included in your user documentation as a system navigation map.

If you don't know how people want to use your system, you can't make it usable. Usage models—such as essential use cases, system use cases and user stories—help explore how people work with a system. Essential use cases are technology-independent descriptions of how people interact with your system. System use cases, also known as traditional use cases, take technology platform decisions into account. User stories are much simpler and smaller than use cases, and are typically written on index cards. They contain just enough information to overview a requirement, and are effectively reminders to you to have a conversation with one or more project stakeholders to identify the details. All three of these artifacts, and more, are overviewed at www.agilemodeling.com/artifacts.

Personas are another useful model in your quest for usability. A persona is an archetype of a real-world user of your system. For example, a persona for the university information system is "Sally Jones, an incoming freshman student from out of state. She has a small scholarship awarded for track-and-field and works part-time as a waitress. She's undecided on her major and is taking a range of courses this year. She lives on campus in a female-only dorm." By identifying a range of personas such as this, you can begin to understand the types, and the needs, of your system's users.

Implementation Techniques
Several UI implementation techniques and technologies are available; first is traditional UI prototyping—a "working" mockup of part or all of the user interface. UI prototypes enable you to quickly explore, and discard, potential UI designs.

Another option is to simply develop your system's UI, along with the rest of it, in an evolutionary manner. This way, you don't make any investments in throwaway prototype code, nor do you raise any unrealistic expectations among your users—once they're satisfied with the UI prototype, stakeholders may unrealistically insist that you install it tomorrow when you still have several months of work left to do. Unfortunately, you build the UI slowly over time and are unable to quickly provide an overview of the entire system.

Because agilists work in an evolutionary manner, they must refactor their user interfaces just as they refactor their application source code or database schemas. A user interface refactoring is a small change to your UI that improves its design without changing its functionality. Examples of UI refactorings include Align Labels Consistently, Apply Common Color Scheme and Size Fields Consistently.

Recently, I ran into a nifty modeling aid: 6PM's AXLE Prototyping tool. It offers screen sketching and low-fidelity prototyping, and provides magnetic UI widgets that you put on a whiteboard and draw around as needed (see "It's a Gem"). Once you're happy with your prototype, you take a digital photo of it and then process the photo with the AXLE software to produce working UI source code. AXLE Prototyping can currently generate Visual Basic .NET, C#, ASP.NET, J#, Java desktop and Java Server Page code. Although the product's one drawback (at least with the current version) is the necessity for a magnetic whiteboard, this is a "Why didn't someone think of this years ago?" gem.

Essential Skills
User interface skills are critical for all developers, regardless of how agile you are. You don't need to be a usability expert, but you do need to appreciate the fundamentals of UI development if you truly want to be effective. The easiest way to gain these skills is to work closely with someone who already has them. Also, do some reading and take a training course—a great starting point is www.foruse.com.

Once you put usability at the forefront of your project planning, you'll be surprised how quickly your users become convinced that you're one of the best developers out there.