Enterprise UI Design Patterns - Part I

This is in 3 parts:

Enterprise UI Design Patterns - Part III

Summary

Yesterday, I wrote an answer on Quora about best practices for creating design patterns for your org and thought I would expand on my experience creating a enterprise-scale pattern library. This first of three parts is where I talk about the background and initial work.

I was contracted to a large company to create a UX pattern library. The part of the company that I worked in produced customised websites for a number of the organisation’s clients. Until recently, each project was designed and built on an individual basis which led to difficulties when making changes along with slower design and development.

To tackle these challenges, the company was converting to a new content management system (CMS). This allowed them to speed up production but producers were still re-designing common parts across projects which was inefficient. Design would begin from a blank page, acceptance criteria for user acceptance testing (UAT) had to be crafted from scratch each time, and planning estimates were done on the basis of experienced guesses (which tended to be very accurate but only when done by the experts – many on the business side were not in a position to readily provide estimates to clients).

My task was to create a UX pattern library for the new CMS. A number of benefits were anticipated for stakeholders. Producers could speed through common design issues by using pre-defined patterns and spend more time on the difficult stuff; testers could use pre-defined acceptance criteria and know that anything covered by a pattern had already been tested extensively; developers could see the impact of change before it happened; planners could make even more accurate estimates; and managers had a better idea of what was going on.

From the start, there were a number of problems that needed solving before work could begin on creating a library. The first was to clarify exactly what the business requirements were.

The primary business aim was to improve efficiency of the producers’ work without impinging upon any other stakeholders. The first step was to research how the producers actually produced which turned out to be “fairly inconsistently”. This meant that any interface with producers had to encourage adoption – it had to be a pain for producers not to use it.

The next step was to agree what a pattern was. I began by investigating a number of available pattern libraries. After much looking, I almost considered recommending their use but there would clearly be a problem in adapting these patterns to the use cases of the producers.

But some other things were nagging me: the existing libraries seemed incomplete: they didn’t address user goals, rather sub-goals; and there was no link between the two. User experience needs to have a focus on the overall picture as well as the fine detail so we couldn’t use the online versions. Online patterns also didn’t have the extra information that we needed.

From this, I saw that we needed to define what a pattern was in terms of providing a useful pattern library: what unit provided improved producers’ efficiency the most.

Also arising was the issue of specificity:if a pattern was too specific, it couldn’t be adapted to a slightly different context, at least not without significant work. Then again, if I abstracted a pattern too much, it wouldn’t be applicable to any practical use. A fine line had to be walked between abstraction and practical detail. Where this line was, I wasn’t sure but I’d have to use my experience and judgement to begin.

What is a pattern?

The official definition might differ from this one and, as I said earlier, a lot of online resources seemed to consider patterns to be more w widget definition. Though useful for developers, for UX designers, there is little real utility. Our aim is to prevent users encountering problems, or helping users solve problems as effectively as possible.

So what I considered to be a pattern was already differing from everyone elses which didn’t seem a good start even if my concerns about existing patterns seemed justified.

I spent some time thinking.

If you see a UX designer / researcher sitting down in a quite place apparently doing nothing, please don’t interrupt us unless the building is on fire. This job does require us to spend time mulling things over; and mull with this issue I did until the solution hit me.

We shouldn’t use the existing online libraries but rather define our own based on a definition of pattern that fits our purposes.

Now clarified, I could begin defining our patterns. My over-riding concern was that any library just documents widgets. Widgets by themselves rarely, if ever, meet user goals – they are simple a point of information exchange between the user and the system. This explains why UX people are rarely concerned with skins because there is no information exchange.

Instead, we needed each pattern to address a user goal. For example, virtually all of our clients required access to restricted information; in order to get access, they had to first verify their identity and be authenticated (in other words, say, “Yes, this is me!” to a system). This couldn’t be a one-off task completed just once in a person’s lifetime.

So we needed an authentication pattern. Something that allowed users to sign in. But of course, they commonly need to register; or retrieve a forgotten password; or enter a special membership number somewhere.

But the high level authentication pattern was looking either rather bare (for brevity, a lot of information had to be excluded) and was therefore impractical; or it was too complicated because it tried to handle the entire process: producers would get lost in the mass of information.

My solution was to use a hierarchy of information: a lower level set of patterns and a higher level set of patterns of patterns – or what I termed macro-patterns.

Macro-patterns to me described something like authentication at a very high level. When you remember my point about not being too specific and not too abstract, the problems are apparent. The macro-pattern was suitably unspecific but not practical enough. The lower level patterns, however, provided that detail. Each separate part (in terms of a distinct user goal like ‘sign in’ or ‘register’) was defined separately. These I termed just patterns.

But of course, I couldn’t be certain with just my own opinion. I chatted with some UX people and producers; and also discussed this in a meeting with stakeholders. Against expectations, there was consensus that I was on the right lines here.

With a 2 layer hierarchy of patterns, the specificity issue was partly dealt with too: macro-patterns could happily stay at a high abstract level while I worked on the normal patterns detail to ensure enough useful information was being communicated to producers.