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