Enterprise UI Design Patterns - Part III

Enterprise UI Design Patterns - Part III

Summary

After Enterprise UI Design Patterns parts I and II, this final part is where I talk about getting the pattern library working within the enterprise.

Enterprise UI Design Patterns - Part I
Enterprise UI Design Patterns - Part II

Validation

Once we’d documented a few patterns, we went back to stakeholders to get them validated against stakeholder needs. They were considered in detail and suggested amendments were incorporated into the existing patterns. Once we felt confident that we were on the right track, we began documenting the full range of patterns in all detail.

Acceptance

One of the most important stages, we had to get the patterns accepted by the primary target audience: the producers. The patterns had to complement their work as much as possible for them to be useful.

One of the stakeholders was a representative of the producers who ensured that producers’ needs were communicated during the development of the pattern library.

The primary delivery channel was to have the patterns as Word documents. This was not ideal but helped us to put the documents up quickly in order to get feedback on them.

We planned a more interactive delivery system. Within this system, producers could search against tags / keywords; or they could begin by viewing macro-patterns. This allowed them to drill down into the patterns themselves.

Within each pattern, they could view the range of associated wireframes and click on components / widgets to see details. So if a producer, for example, was viewing a sign-in pattern, they could examine each constituent component like the grey prompt text within the text box. This component’s details would tell them that the text could be changed to fit the client’s style of content and other such things.

The advantage was that when producers were designing, they could make sure that they didn’t miss out any configurable items.

Findability

This was crucial to uptake: Producers had to be able to find a suitable pattern once they had framed a problem. Research, however, showed that different producers framed problems in subtly different ways using different terms. Sign in for one producer was log in for another and authenticate for a third.

Each pattern contained a number of tags to deal with synonymy.

Change control

We were also aware that patterns could be improved even if the first draft was based on current practice. This meant that we needed a change control procedure to understand the impact on clients’ sites if changes were brought in.

Any provisions will depend largely upon the organisation that uses the library but our solution was to hold regular meetings to discuss any proposed changes. Such initiatives could come from a variety of sources: from producers, from UX people, developers, business or clients.

To aid this, we proposed a librarian role where someone acted as a gatekeeper to collate and present information to this committee. This librarian acted as a first port-of-call for library change requests and could begin a preliminary assessment before presenting them to the change control committee.

We also realised that there might be emergencies when we couldn’t wait for these meetings so the makeup of an emergency committee was proposed. Members (or representatives) taken from the stakeholders were to be available at very short notice to discuss changes.

Greatest Effort

Even though a great amount of effort was made to produce the library, it was aimed to work within a Lean development environment. This seems paradoxical, that so much work goes into something like this but we had to provide a fertile enough environment for producers to be able to work. Because design needs to be one step ahead of development in Agile processes, having a large set of documentation ready would be invaluable.

The cost of time, however, needed to create such a library from scratch is probably only possible for a larger organisation with many clients. This is where the benefits of a pre-made library can most be felt. Within smaller organisations with fewer clients, the initial investment may be hard to recoup unless spectacular growth is anticipated.

The greatest effort I made was in getting the content of the library correct. This involved scouring existing clients’ sites to elicit designs and break them down into their fundamental interactions. This level of abstraction needs to be undertaken by an experienced user experience practitioner, or someone who readily understands what degree of information is necessary to use the pattern.

A surprising amount of time was spend thinking through how to get the project off the ground but this article should help avoid some of the pitfalls.

Go back to Enterprise UI Design Patterns - Part II
or go back to Enterprise UI Design Patterns - Part I