A user interface specification (UI specification) is a document that captures the details of the software user interface into a written document. The specification covers all possible actions that an end user may perform and all visual, auditory and other interaction elements.[1]
Purpose
The UI specification is the main source of implementation information for how the software should work [citation needed]. Beyond implementation, a UI specification should consider usability, localization, and demo limits. A UI spec may also be incorporated by those within the organization responsible for marketing, graphic design, and software testing. As future designers might continue or build on top of existing work, a UI specification should consider forward compatibility constraints in order to assist the implementation team.
The UI specification can be regarded as the document that bridges the gap between the product management functions and implementation. One of the main purposes of a UI specification is to process the product requirements into a more detailed format. The level of detail and document type varies depending the needs and design practices of the organizations. The small scale prototypes might require only modest documentation with high-level details.
In general, the goal of requirement specifications are to describe what a product is capable of, whereas the UI specification details how these requirements are implemented in practice.
The process
Before UI specification is created, a lot of work is done already for defining the application and desired functionality.
Usually there are requirements for the software which are basis for the use case creation and use case prioritizing. UI specification is only as good as the process by which it has been created, so lets consider the steps in the process:[2]
Use case definition
Use cases are then used as basis for drafting the UI concept (which can contain for example main views of the software, some textual explanations about the views and logical flows), these are short stories that explain how the end user starts and completes a specific task, but not about how to implement it.
The purpose of writing use cases is to enhance the UI designer understanding of the features that the product must have and of the actions that take place when the user interacts with the product.
Design draft creation
The UI design draft is done on the basis of the use case analysis. The purpose of the UI design draft is to show the design proposed, and to explain how the user interface enables the user to complete the main use cases, without going into details.
It should be as visual as possible and all the material created must be in such a format that it can be used in the final UI specification. (This is good time to conduct usability testing or expert evaluations and make changes.)
Writing the user interface specification
The UI specification is then written to describe the UI concept. The UI specification can be seen as an extension of the design draft that provides a complete description that contains all details, exceptions, error cases, notifications, and so forth. The amount of detail provided depends on the needs and characteristics of the development organization (scope of the product, culture of the organization, and development methodology used, among others). Usually, the UI concept and specifications are reviewed by the stakeholders to ensure that all necessary details are in place.
Structure
Having a formal structure for a UI specification will help readers anticipate where they can find the needed information to interpret the specifications correctly. Example structure of the UI specification may contain, but not limited to, following items:
- Change history
- Open issues
- Logical flow
- Display descriptions
- Error and exception cases
The specific contents will vary to be appropriate to the organizational needs (another example is Nokia's UI Specification structure[3]).
Change history
Having an informative change history helps the reader to see what, when and why something was changed. A UI specification quite often changes during implementation.
Open issues
Possible open issues. While there are unclear or open issues, those can be visible.
Logical flow
The logical flow can be used to give high-level view of how different screens in the user interface relate to each other to support a task. Flow can reveal for example number of required steps to perform certain task.
Display descriptions
The display description contains the screen contents and information about available functions. The screen contents may be wireframes, screen-shots of a prototype, or UI mock-ups.
A picture of the user interface state will provide a quick overview. Wireframes are recommended over high resolution graphics. Caution should be taken in providing too polished a picture as details might change and time and resources have to be allocated to redraw pictures. Additionally, readers may become distracted into commenting on visual design elements such as color choice and images that were intended to be placeholders and not reflective of the final product.
In addition to a picture of the display, access points should be listed and the fields and controls on the screen should be described. The following table gives a list of the bare minimum you should be describing:
| Element |
Description |
Comment
|
| Label |
Label on the screen |
if the element has no label, number it and refer to it by number
|
| Description |
Describe the element |
its type (input, drop-down, calendar), what it does, etc.
|
| Default value |
what the field defaults to if no value is provided |
May not be applicable for every type of screen
|
| Values |
List boundary conditions or error conditions |
i.e., Dates must be in the past, integer numbers from 1 to 100
|
Error and exception cases
Indicates how to display information regarding any network issues or other events that require error indications to user.
References
