User Experience Design

User Experience is simply the total interaction that a user has with your product. It’s more than the user interface because it includes all facets of the product, such as documentation, marketing literature, release notes, and, of course, the user interface.

The typical process in most companies is to create a high-level requirements document that defines product features to be delivered in a given release. Engineering then creates technical specifications to define how to technically accomplish these requirements. (An example is an architecture specification.) What is often implicit or not defined at all is the human/product interaction.

The omission of a clearly defined user workflow and behavior leads to usability and customer problems. More immediately, though, this omission causes lost time in development. The developers will have questions or misunderstandings about how the product works. In the end, time is wasted and the product at the end of the development cycle does not meet the initial vision or customer requirements.

There’s an opportunity here to save even more time and improve the overall quality of the product. But first, let’s define a couple of terms.

User Workflow
The User Workflow is simply the procedure the user follows to accomplish a specific task. For example, the user's goal is to send email to convey important information. The workflow would include opening a blank email window where the user can type the message, prompting for the name of the recipient and a subject title, and sending the message. Additional features, such as a spell check, could be included in the process.

The User Workflow must clearly specify each step in the process in detail. The details include which buttons to press, which fields to fill in, what messages or prompts appear, etc. The workflows essentially define the user interface. It also ensures that the product does not have any "dead-ends," where the user cannot complete a task with the product.

Along with the workflow, the behavior of the UI must be clearly specified.

UI Behavior
The behavior of the UI is the product's reaction to any given input. This is very detailed. For a software product, it means specifying the product's reaction when each button is pressed, an option is selected in a menu, or a user provides input. The following shows a simple example of a behavior table entry:

User Action: User selects a file and clicks the Delete button.
Product Action: The file name is highlighted and a message box pops up: Delete the file permanently? [Yes] [No]

Ideally, the behavior specification should include all the details for every possible input, including the product's reaction when a user performs a task out of sequence. In addition, the behavior specification must follow the user workflow very closely.

What RGovoni Offers
Before coding begins, we map the user requirements to user tasks. Then we create basic user workflows of how the user should accomplish those tasks. Once done, we write the behavior specification and design the screen layouts.

Depending on the complexity of the product and your company's internal processes, the tasks, workflows, and behavior specifications can be presented in a variety of formats. For example, this information could be its own specification, part of a larger specification document, or even as XML DTD elements in a single sourcing system. The format and presentation of this deliverable is certainly negotiable.

A secondary deliverable can be the training of one or more individuals to update this information with every product release.

Not-So-Serendipitous Advantages
In medium to large development groups, it is very easy for different developers to have a slightly different understanding of how the product actually works. This can reflect in how they code a particular function. The obvious advantage to specifying the UI workflow and behavior is that the product developers have clear specs from which to write code and develop the product. Yet, there are a number of other groups that benefit greatly from this information.

Quality Assurance: A good test plan requires a thorough understanding of all expected product behavior. Any expected behavior that is not made known to the test writer does not get tested, leaving bugs to be found by customers. By documenting the product behavior, the test writer has all the information necessary to write comprehensive test plans before the product is available for testing.

Documentation and Training: Technical writers spend much of their time researching how the product works then understanding how the users are expected to use the product to accomplish tasks. The time spent gathering this information leaves little or no time to document additional useful information to customers. The product behavior document provides a lot of the basic information, reducing research time and misinformation. The specification can aid in the formation of an information architecture or document design.

Remote Engineering: In cases where engineering is done in a remote location, the product specification is critical. Especially where there are cultural and language differences, it is very easy for different developers to have a slightly different understanding of how the product actually works. This can reflect in how they code a particular function, creating barriers to success.

Customer Support, Marketing, and Sales: Between departments, it is easy for misinformation to occur. With different people gathering information from different sources and filling information gaps as they occur, final product information can lack critical details, can conflict among different sources, and can even be erroneous. This can cause misunderstandings among product management, sales, marketing, and engineering. A detailed product behavior specification can be a definitive source of information from which to clarify what customer tasks are supported and how.

The Next Release
The user workflow and behavior specification makes it easier to review how the product interacts with customers, and how to improve the user interface for usability. An example is that the product does not provide appropriate feedback in response to a user action, which ultimately causes a product failure. These problems can be uncovered and addressed before the next release of the product.

Back to Top