17 January 2012

Enterprise UI Design Patterns - Part II


Enterprise UI Design Patterns - Part II

Summary

Following on from Enterprise UI patterns - Part I, this second part of three is where I talk about the content of a pattern.
Enterprise UI Design Patterns - Part I
Enterprise UI Design Patterns - Part III

What content goes in a pattern?

The fundamental contents of each pattern were based around the producers’ primary needs for design and development. These were:

Item of content
Rationale
A descriptive title
Immediate information about the pattern; reference.
A unique code to identify each pattern
Uniquely identify a particular pattern, version, wireframe, and component
A description
More information about the pattern than just its name
Tags / keywords
Findability
A list of user problems that the pattern should help solve
Place the pattern into its context as it relates to users
Acceptance criteria
Used by producers and user acceptance testers to validate a project
Workflow
Describe the user flow and journey through the pattern at a high level
Wireframes and specification (including configurable items)
Detailed visual information about the pattern (often done in Balsamiq)
Examples of use in existing websites
Screenshots of the pattern in use

The configurable items were referenced (each with a unique code) in the wireframe. This meant that producers had an immediate coverage of what things could be configured which made the design of common components more straightforward. Examples of the pattern in use helped to illustrate the pattern. Producers rarely needed this information and it was included mostly for staff outside of the unit and for clients.

A miscellaneous section was created with contents guided by stakeholders’ needs.

Item of content
Rationale
Where the pattern is currently used (generally within the company’s stable but sometimes we referred to external examples)
Understand the impact across all clients’ websites if changes are made
User states and associated information
Understand complexity
General UX principles underpinning the design decisions
Useful for re-design
Alternative patterns (other ways to solve the same user problems)
Allows producers and clients to see different ways to solve the same user problem and get work / time estimates
Related patterns (generally those within the same macro-pattern)
A family that contribute towards a higher-level user goal
Testing and research related to the design decisions
Provides justification about design decisions
How not to do it (anti-patterns)
Informs design decisions
SEO recommendations
Provide good SEO
Estimates of work and time for implementing a pattern
For planning / estimating the resources needed for a project
Version history
To track down particular versions

Incorporating user stories as acceptance criteria for user acceptance testing

The organisation used an Agile method of production. When a project went into user acceptance testing, a number of acceptance criteria were generated from scratch and the project tested against them. These criteria often came from user stories.

·      Pattern definitions incorporated these criteria which provided benefits:
  • ·        User acceptance testers had ready made criteria - these were already embedded into the pattern
  • ·        Each pattern would be working having already been validated
  • ·        UAT could be automated to a greater degree
Go on to Enterprise UI Design Patterns - Part III
or go back to Enterprise UI Design Patterns - Part I


No comments: