User Interface

Design > User Interface

Release Information

Project:	PROJECT-NAME
Internal Release Number:	X.Y.Z
Related Documents:	LINKS-TO-RELEVANT-STANDARDS LINKS-TO-OTHER-DOCUMENTS

Overview

TODO: Answer the questions below to help you design the user interface features of your system. Consider how the provided sample text relates to your project. Then, add, edit, or delete text as needed.

What are the most important facts that a developer should know about the user interface of this system?

The core of the UI design is SCREEN-NAME, divided into NAV-PANEL, MAIN-PANEL, and PROPERTIES-PANEL. Start by understanding the dependency between the selected object in each and the contents of the others. Then, study DIALOG-NAME. After that, you will have a much easier time understanding the other screens.

There are a few key concepts in the UI design that should never be violated:

The UI design is driven by the use cases, not the other way around.
The overall set of screens is organized into zones. All screens in a given zone use the same layout and have the same security constraints. Do not add a new zone without consulting PERSON-NAME.
Each screen is composed of branding, zone-specific navigation, screen prompt, data display / fields, and available operations.

Please keep in mind that we started using LEGACY-DESIGN, but we are in the middle of a long term transition to NEW-DESIGN. We are converting one entire zone at a time.

What are the ranked goals for the user interface of this system?

Metaphors, Exemplars, and Standards

What is the central metaphor of this UI design?

The e-commerce website engine provides a UI that works like a product catalog and mail-order form. The product review feature works like a discussion forum.

This is a desktop application that follows the widely used document metaphor: a computer file is thought of as a paper document.

The user will think of the application as an interview with an expert in APPLICATION-DOMAIN leading to production of a TANGIBLE-CUSTOMER-BENEFIT. Depending on user input, the system may connect to one of our human experts for additional advice.

The central metaphor is the shareholder portfolio. Each portfolio lists shares held and their values. Many of the tools analyze or visualize a portfolio as a whole.

Users may think of the application as a REAL-WORLD-SITUATION. The PART-OF-APPLICATION is like a FAMILIAR-OBJECT.

What existing systems have user interfaces similar to the UI you want to build? What specific aspects are similar?

amazon.com: Our e-commerce site will have stores and departments, and search like this site.
Microsoft Office: We will use configurable toolbars the same way that Office 2000 does.
EXISTING-UI: DESCRIPTION

What UI design standards, guidelines, and styles are you following?

Task Models

What types of users will use this system?: See the user needs document.
What types of tasks will those users perform?: See the use case suite.

Screens

TODO: Briefly describe each screen in the system. Focus on the purpose and content of each screen rather than its appearance. Each screen is actually an interaction context.

Design a set of UI zones.
List each screen with its purpose.
List the abstract contents of each screen and describe their behavior.
Evaluate the UI model by walking through use cases.
After initial usability evaluations, make a few key design decisions about layout and appearance, if implementation guidance is needed.

Zone: Public pages

Web pages that may be accessed by logged in users or other unauthenticated visitors. Pages contain information about the website and product information. Many navigational and search choices are offered.

Screen Name and Purpose	Contents	Behavior and Constraints
Store home page Showcases the products that are selected by administrators, e.g., best selling, or overstocked. Provides quick access to most major parts of the site. Easy access to site search.	Welcome message Site news Top selling products Large graphic of ideal customer lifestyle Links to departments and key categories	News items are sorted by date Top selling products are sorted by number sold
Department home page Showcases selected products within a given store department. The items are selected by a product manager. Provides quick access to each category of products in the department, and easy access to department-wide and site-wide search.	Large graphic of product use Department top sellers and specials Links to categories and key products Buyers' guides	Top selling products are sorted by number sold Order of specials set by department manager
Product info page Presents all public information about a given product: name, price, manufacturer, SKU, description, specs, consumer ratings and reviews, etc.	Basic product info: name, image, SKU, manufacturer Product price: regular price, and optional sale price Availability: in-stock, back-ordered, discontinued Product details: description, specs, additional images User ratings and reviews	Price information not shown if discontinued If sale price, then regular price is crossed out Additional images shown in pop-up slide-show

Zone: Registration and Authentication

Screens that help users set up accounts and log in.

Screen Name and Purpose	Contents	Behavior and Constraints
Registration page Allow a new user to sign up for an account.	Prompt: Tell us about yourself Message display Real name field Email address field Desired username field Opt-in marketing choices Register button	If registration fails, message area shows error message and invalid fields are highlighted. Username must validate according to username requirements in feature spec. Invalid or duplicate usernames are rejected. "Register" is only enabled when fields have valid values. Some of the opt-in marketing choices will show the logos of partner companies.
Login dialog Verify that the current user is actually the person that he or she claims to be.	Prompt: Please log in Message display Username field Password field Login button Forgotten password link	Message area is initially blank. Changes to "Checking username and password" when the user presses "Login". Changes to "Invalid username or password, please try again", if login fails. Username must validate according to username requirements in feature spec. "Login" is only enabled when Username != "". If the username or password is incorrect, delay a few seconds, and then clear all fields. There is no separate "login failed" page or "try again" page.

Zone: Checkout pages

The pages in this zone help the user complete his/her purchase. Almost no navigation options are offered, because we want the user to finish checking out before doing anything else, even if that is slightly inconvenient. If the user is not logged in, they must log in (and possibly register) before proceeding past shopping cart review.

Screen Name and Purpose	Contents	Behavior and Constraints
Shopping cart review Users can see the contents of their shopping carts and change product quantities.	Cart contents and (editable) quantities Option to continue shopping Subtotal of item prices	Note that there is no single command to empty the cart. Option to continue shopping needed in page because there is no navigation bar Editing a quantity immediately updates subtotal
Billing and shipping choices Users can arrange for product shipping.	Choice of billing methods Billing address Shipping address (if different) Choice of shipping methods	Billing methods and bill-to addresses are not stored in the user account. Shipping address fields are disabled, unless "Ship-to:" check-box is marked. Choices for shipping method are updated based on destination address (because not all shippers serve all destinations).
Order confirmation Users review and confirm their entire purchase.	Read-only copy of all purchase info. Total amount Estimated arrival date Option to go back Command to confirm order	Total amount includes sales tax based on billing address. Confirming an order empties the shopping cart. QUESTION: where should coupon codes fit in?
Order record Summarize a confirmed purchase.	Message: Thank you for your order Prompt: Please print this page for your records Read-only copy of all purchase info. Total amount Estimated arrival date Option to return to shopping	None

Zone: Individual user information

Pages of information about the current user account. The user must be logged in to access these pages.

Screen Name and Purpose	Contents	Behavior and Constraints
User profile Allow a user to view and edit his/her account information and preferences.	Prompt: This is your account information Real name field Email address field Username field (read-only) New password field New password repeated field Opt-in marketing choices Update button	Password must pass quality checks. "Update" is only enabled when all fields are valid.
My reviews Allow users to see all product reviews that they have written.	Prompt: These are reviews written by you. List of product reviews: Date review was written Product name, link Rating given / Current average rating Text of product review	Reviews may be sorted by date, given rating, or current product rating.

Zone: Administrative pages

Administrative pages are only accessible by system administrators. These pages need not have the same look and feel or navigational elements as the other zones.

Screen Name and Purpose	Contents	Behavior and Constraints
Site configuration page Allow administrators to configure several aspects of the site behavior and defaults. See F-00.	Site look and feel options Default timezone and locale Session settings Security settings Options to control specific features	TODO
Edit product information Presents product information and allows an administrator to edit. Also presents product traffic and sales information.	Basic product info: name, image, SKU, manufacturer Product price: regular price, and optional sale price Availability: in-stock, back-ordered, discontinued Product details: description, specs, additional images User ratings and reviews Product sales stats: selections, purchases Traffic stats: page views, referrers, search terms Additional operations: discontinue	All fields basic, price, and detail fields are editable. Stats may be viewed in periods of day, week, or month. Sale price, if given, must be less than regular price

Zone: UI-ZONE-NAME

DESCRIPTION OF ZONE

Screen Name and Purpose	Contents	Behavior and Constraints
SCREEN-NAME PURPOSE-OF-SCREEN	PROMPT FIELD-NAME FIELD-NAME AVAILABLE-ACTIONS	BEHAVIOR CONSTRAINT NOTE QUESTION
SCREEN-NAME > PANEL-NAME PURPOSE-OF-PANEL	PROMPT FIELD-NAME FIELD-NAME AVAILABLE-ACTIONS	BEHAVIOR CONSTRAINT NOTE QUESTION
SCREEN > PANEL > ELEMENT-NAME PURPOSE-OF-ELEMENT	ELEMENT-CONTENTS	BEHAVIOR CONSTRAINT NOTE QUESTION

Technical Constraints / Operational Context

What are your assumptions about the output devices?: We assume that the user has a 17-inch or larger screen with 1024x768 pixels that can display thousands of colors (16 bit or more). We assume basic audio that can play simple sound files.; We make very few assumptions about the user's screen or web browser, other than the assumption that they can view each page. We will not use any audio features.; This "pay-at-the-pump" system has a 320x200 16-color display and can beep.
What are your assumptions about the input devices?: We assume only that the user has a standard keyboard and mouse.; We make very few assumptions about the user's input device, other than the assumption that they can select links and enter text into form elements.; This "pay-at-the-pump" system has digits 0-9, "OK", "Cancel", and four menu buttons along the right-hand edge of the screen.
What are your assumptions about the amount of time users will spend on tasks?: Use cases UC-02 and UC-04 are expected to take a few minutes each. High frequency use cases should take less than 5 seconds for each occurrence. All other use cases should take less than 30 seconds each.
What windowing systems, UI libraries, or other UI technologies will you use?: Standard Java Swing with no extra libraries.; Simple HTML and CSS with simple GIF images.; Standard desktop GUI libraries for PLATFORM.

User Interface Checklist

TODO: Answer the following questions to help evaluate your design. The sample answers are meant to prompt you to think critically about your own design.

Understandability and learnability

Are there any labels or icons that are likely to be misunderstood?: No. We have reviewed all labels and they are all standard and/or very clear.; We don't think that we have created any difficult labels or icons, but we are not sure.; Yes. We know that the following may be hard to understand and we are tracking the issue: LABEL, LABEL, ICON.
Is the user's current place and state clearly visible? E.g., wizard step 2 of 5, or edit-mode vs. command-mode.: Yes. We have designed and reviewed a navigation system that clearly presents the needed place and state information.; The process of using this product is pretty clear. We have some feedback built into the UI and it should be good enough.; No. When the user is on SCREEN-NAME, they have no idea how long the process will take. It is too difficult to tell if a user is in MODE-A or MODE-B. There is no way to tell if the currently open document needs to be saved.
Are advanced options clearly separated from the most commonly used options?: Yes. We have a consistent convention of using "Advanced..." buttons to expose advanced options that are otherwise hidden to reduce distraction during the most frequent use cases.; We feel that a user who knows how to use this product should pretty easily realize which fields in a dialog are advanced. The terms in the field labels and their position imply basic vs. advanced usage. Users can just ignore fields that they do not need.; No. We know that users spend too much time scanning our screens for elements used in frequent use cases. They spend too much time, in part, because our screens are cluttered with rarely used advanced options.
Are there any invisible options or commands? E.g., hold down the control key when opening a dialog box to see advanced options.: No. The user can find every user interface affordance by visually scanning the screens. The only exceptions are pop-up context menus that offer commands that are also in the main menus.; A few. We support some modifier keys that the user would never be able to guess without studying our keyboard shortcuts page.; Yes. Big parts of promised functionality will be accessed through a configuration files, a scripting language, or command-line arguments that users could never guess without studying our documentation.

Task Support and Efficiency

Which use cases force the user to work through more than two screens?: None of the high frequency use cases requires more than two screens. Only UC-10 and UC-20 require three screens.; Several use cases require three screens, but no use cases require four.; We have a known problem that one of our most frequent use cases requires too many screens: UC-30. This issue is being tracked.
Which use cases force the user to perform slow or difficult UI steps? E.g., entering a long code number like an ISBN. E.g., long mouse-drag operations.: We have reviewed every use case and screen and we have eliminated any difficult steps. Users never need to enter information that it is not reasonable to expect them to have memorized, e.g., their own name and address.; Users need to make selections from long lists by remembering the meaning of obscure codes, e.g., two-letter US state abbreviations.; Users must perform several difficult steps in one key use case. E.g., they must see a six-digit shipment ID number on the product inventory management screen and then remember and select the same code number on the backorder screen. We will review the UI for other difficult steps by MILESTONE.

Safety

Are there any dangerous or irreversible actions that are done with only one step?: No. All dangerous or irreversible actions require a confirmation.; The actions that seemed obviously dangerous have a confirmation step, but we have not reviewed the UI to find all such actions.; Yes. We have not had time to put in guards against accidental deletion or other dangerous actions. We are tracking this issue.

Consistency and Familiarity

Do UI elements in your system work the same as they do in the existing exemplar systems listed above?: Yes. We know that they work the same because we have reviewed the UI with this in mind.; They should work the same because we did not purposely do anything different.; No. We are trying to do something new and more powerful that goes beyond existing systems. Our UI looks like it should work in the familiar way, but it does not. We are tracking this issue and will evaluate it further.
Do all elements in your system that appear the same, actually function the same?: Yes. We reviewed the UI to make sure that every time that a label or icon was used in two places, it means the same thing.; We should be OK because we never purposely used the same label or icon for two different meanings.; No. We are using the same label or icon in multiple places with different meanings and users could be confused. We are tracking this issue.
Do all elements share consistent visual characteristics such as font and color scheme, unless there is a reason for them to differ?: Yes. We have a very consistent style sheet and there is no one-off style information in the screens themselves.; We should be OK because we never purposely varied the style of any elements.; No. We have hard-coded style information in several places and it is too hard to keep it consistent when we make changes.
Are labels used consistently throughout the system? E.g., not "forward" & "back" in some screens and "next" & "prev" in others.: Yes. We have factored all label text out into a simple data file (needed for internationalization) and reviewed that file for consistency.; We should be OK because we never purposely used inconsistent labels.; No. We definitely use different labels for the same function in different screens. This does not bother us, but it could confuse users.