Graphical User Interface Specification Template

Question

At my job we put some elements of the design for graphical user interface in both the functional specification and the technical design documents. However, this is often easy as nearly 100% of the time we are making modifications to existing software.

What would one do if they wanted to produce a separate document for GUI specification that was for a new software project? I have software that can help me with simple wire frames, but what would a document template outline look like. What do you use for a template or outline?

Answer 1

I was part of a group a few years back that had a very good UI specification process. We created a document that contained:

1. An overview of the overall UI metaphor (e.g."Page and Folder", "Business Card")
2. Proposed UI elements (e.g. the help buttons including the icons, the styling to be used on pull-down lists, etc.). These all supported the metaphor.
3. Specifications for spacing and justification standards for dialogs (all had 8 pixels or border, buttons below list boxes were always x pixels away, etc.).
4. Font specifications (ours was to be a very stylistically unique project)
5. We included specs on how to provide 'Help' but this was a bit unusual
6. Candidate screen mock-ups that incorporated the UI elements and that demonstrated the metaphor.

UI documentation is not meant to capture every screen and every dialog. However, it must have enough information that someone reviewing the spec would gain a very clear idea of the look and feel of the application. We also took some pains to spell out key dialogs or those where the metaphor was particularly important.

One last thing, when we did the specification, we worked with a graphic design group that actually created several initial, candidate versions. After the team members voted on the candidates, we took the winner and fleshed it out in much more detail.

Answer 2

I think paper prototypes are an important part of early UI development and specification.

Have a look at the lecture notes here:

http://ocw.mit.edu/OcwWeb/Electrical-Engineering-and-Computer-Science/6-831Fall-2004/CourseHome/index.htm

I think it's important to note that good GUI specification should contain a set of guidelines/principles for the entire project, to ensure consistency. I usually inherit from a well established set of guidelines (EX: http://download.microsoft.com/download/e/1/9/e191fd8c-bce8-4dba-a9d5-2d4e3f3ec1d3/ux%20guide.pdf) and then list any differences.

For individual forms, components, etc... I specify the general design using Pencil with a lot of annotations:

http://www.evolus.vn/Pencil/

...which allows for platform-agnostic rapid ui prototyping akin to paper prototyping. It's still important to use paper prototypes for anything that non-designers will likely want to change. Users are more likely to suggest changes if the design looks impermanent (this is why cab software can make printouts with degraded sketch-like quality).

Also, I've found it's helpful to have a UI design acceptance testing phase. All project stakeholders should sign off on the UI design before it's implemented. After all, to most non-technical computer users, the user interface IS the application.

Answer 3

Consider if the GUI specification is required for commercial or design reasons?

The depth of detail required of a GUI specification will generally be driven by the commercial requirements of the commerce surrounding the software project rather than the end user requirements. A GUI specification that contains extensive details such as font selections, icons, pixel border widths etc is generally created so as to capture the scope of the project so as to avoid potential commercial disputes at the end of the project.

My experience is that asking the customer (end users) to make selections on lots of small GUI details at the start of the project only adds unnecessary noise to the overall customer engagement.

Iterate The GUI Specification

If it is a new software project (as mentioned in the question), then often the GUI needs to be discovered by all team members, developers and end users included. Therefore I would suggest taking an iterative approach to your GUI specification. Start simple, only a few screen shots, that when combined allow the user to complete something useful (this could be one or more use cases). Then each subsequent iteration adds more appropriate detail.

---

What does a GUI specification document template look like?

IF the GUI spec is for design reasons; I would recommend a word document with the following structure:

• On the top half of each page place a mock screen shot [a].
• On the bottom half of each page write what you think is important [b] about the above screen shot.

If the GUI spec is for commercial reasons; I would recommend a word document with the same structure as above plus the following:

• Font, color, logos, pixel border widths, glossary etc. Pretty much as much as you can document within the time available.

[a] Tools to generate mock screen shots: Balsamiq, Visual Studio + Snagit with useful comments overlaid are great.

[b] What's important? The short answer is "..it depends.." and it is up to the GUI designer and end users to collaborate so as to discover and then identify what is important.