UX Design Planning

UX Design Planning

Summary

When designing from a UX perspective, I find it helpful to plan all my work in a spreadsheet. This forms a useful reference throughout design and help ensure that requirements are not missing.

The WorkPlan for Design Planning 

When planning a design, UX designers need to take into account a large number of factors. Obviously, we have user requirements and these are often foremost in our minds because it's what we're good at. However, we also need to take into account business and technical requirements: the former because any design has to meet the needs of a business; the latter because it has to be built.

But this can be a lot of work. Mentally juggling all these requirements (which can be contradictory or at least require problem solving) is hard for complex projects. It's easy to forget a single line in a 90-page business requirements document that turns out to be crucial.

So I use a spreadsheet to plan. This workplan is not exciting by any means and certainly not pretty, but it is effective. It's not used to communicate to stakeholders except possibly developers who, on the whole, quite like how explicitly it communicates.

For smaller jobs, I often stick to the simple user journey but limitations of space can make a graphic version quite hard to follow. Using a spreadsheet allows a quick display of information and (when there are time constraints) it's very quick to update it.

The final advantage is that it puts off the process of putting pen to paper until later in the process. Sketching is so much fun that it's tempting to do it early (as I mentioned before, I often do it early as a reality check / interface stressor). I have found myself to be more productive if I can make sure I have all the information requirements (user, business, technical) in place and validated - and a single piece of work containing the lot.

High Level

Like a lot of UX, we begin at the highest level (note: I often try to work at multiple levels simultaneously but that's another article) by noting down the high level structure. This equates roughly to a sitemap.

Each separate area of function / content is laid out in a separate worksheet. Large projects can quickly get very unwieldy but it's easier than referring to work docs, wikis etc.

It's possible to develop the sitemap after this, before this or in tandem with this part. The important thing is to stick with whatever the designer feels is best and the first established element should guide the rest.

Function Level

Within each high level area of function / content, I then note the functionality required of this area. This is again at a higher level than we'll be working to later.

The important content here is a breakdown of the unit of function. Included are the overall aims (user goals), pages that link in and links out, and the fundamental information exchanges. It's possible to begin the information exchanges at a high level and work down (i.e., begin with "Enter user's address" and end up with "User's house number / name", "user's street", "user's postcode / zipcode" and so on.

Specific requirements can be noted here: things like date fields that cannot display after the current date for retrieving historic records.

This plan is a work in progress and will change as the rest of the site or application is developed.

This stage equates somewhat to user journeys: it describes the user journey in detail.

Content Level

With the function in place, we can begin to plan content. Things like necessary legal conditions (if there are terms and conditions, links to these can be included in the links out section if necessary), instructions, and pagination for workflows can be included here.

So now we have a breakdown of a page with all the necessary functionality and information. This defines the information constraints within a page and gives designers a very quick overview of all the requirements that the page has to meet.

The usual process is to get these validated somewhere (this might be with stakeholders, other members of the UX team or whatever the organisation deems best) and then wireframe design fun can begin.

Statistics in UX - Part II

This is the second part of my article on statistics in user experience. Part I is here and discusses types of data. In this article, we begin to see what to do with it.

Descriptive statistics

This is essential to analysing data and represents what some people see as statistics.

Descriptive statistics just describe the data. There are various measurement types that you can use (depending upon what research questions you have) to understand what happened when you took the data.

But first think back to the last article: we discussed nominal, ordinal and interval data. The types of data you have will shape the kind of descriptive statistics you need. There are good reasons behind this and statistics is far from being an academic discipline. It's based entirely upon understanding the world around us.

Measures of central tendency.

These measure tell you where data tends to be centred. The catch-all word "average" covers a number of measures which you have most likely heard of at some point. Each of these measures has assumptions which have to be met before the test can be used.

Mean, or more correctly, the arithmetic mean is a measure used for interval data. It's fairly meaningless in terms of ordinal data and certainly nominal data. Imagine if you did a survey with 100 respondents and 60 of them were women. Can you say that the mean sex of respondents was 1.2?

The mean is calculated as the sum of all values divided by the number of values. So a list of 4 response times [234ms, 265ms, 289ms, 198ms] would have a mean of:

(234 + 265 + 289 + 198) / 4

= 986 / 4

= 246.5.

The mean seems to make more sense for ordinal scales like Likert scales but there is a danger. The mean works well only when there is a normal distribution of data (a bell-curve). Even then, it can be hard to make sense of the data. A better measure to use is the median.

The median is another measure of central tendency that produces the middle value. Imagine if we got all values, sorted them into an order and found the central point. If there is an odd number of values, then 1 value is the median. If there is an even number, then the mean of the 2 central values is the median.

Say we have a 5 point Likert type scale given to 10 people. Responses are [1,2,4,3,5,3,2,1,2,1,2]. Sorted, this list becomes [1,1,1,2,2,2,2,3,3,4,5]. The central values are 2 and 2 ([1,1,1,2,2,2,2,3,3,4,5]) and the mean of [2, 2] is 2! We can say that the median response is 2.

Compare this with the mean which is 2.6 - not vastly different but different enough.

The media is useful when the mean cannot be used: remember the assumption of a normal distribution? Well if you want to calculate the mean of a nation's salary, you will probably not get a normal distribution: rather, it will be skewed to the left (a negative skew) because most people will be earning little and only a handful raking in the millions that we hear about (very extreme and uncommon values are called outliers). Reporting the mean will be meaningless.

The median protects somewhat against skewed data. By taking the central point, a figure more representative is found.

The mode is controversial. Some statisticians say it is a measure of central tendency; others say it is not. The mode is the most commonly occurring value. For interval data (like response times), the mode doesn't make much sense. There may well be no mode because each response time happened only once. But for Likert scale, it makes sense: with the above data, we can say the modal value is 2 because it occurs 4 times which is more frequent than any other value.

It also makes sense to report modes for nominal data. With the above example of sex, we can say the modal value is female (but we'd have to report the statistic, so something like, "Of the 100 participants, 60 were female" is probably enough.

The choice of what statistic to use depends upon your research question. If you're trying to find out the likely disposable income of users, the median will be best. If you're answering a question about tax income on a national level, then the mean is best.

There are other measures of central tendency (harmonic mean, geometric mean and so on) but they are rarely used in UX.

In the next article, I'll talke about measures of variance.

50ms to rate a webpage!

This article was first published on 18 January 2006.

50ms to rate a webpage!

A recent study shows that decisions about webpages may be made in the first 50 milliseconds of viewing. This has implications for website designers. In this article, we investigate this claim.

It’s been widely reported in the media that websites are evaluated in 50 milliseconds - this is all the time that designers have to make a good impression. This article will discuss these findings i) in terms of the quality of the research itself; and ii) if the research is valid, what are the implications for designers?

The paper is by Lindgaard et al (2006), but instead of believing everything I read in secondary sources, I decided to take a look at the actual paper itself. After all, there’s nothing like going to the primary source!

Human visual processing needs a certain amount of time to recognise objects (in the order of a few hundred milliseconds) but emotional judgements are made far more quickly, the authors contend. Further, later decisions about an object are not so much based on rational thought, but instead follow the principles of the cognitive confirmation bias (cognitive constancy) in which aspects congruent to the initial decision are focused upon and used to justify decisions. This means that the very basic elements of layout and design are important in the judgement of a websites quality which reduces the importance of other factors such as the content and facilities.

This study is important because, if valid, it indicates that the aims of usability (to ensure that websites meet the “holy trinity” of being effective, efficient, and satisfying to the user [ref ISO9241]) may be less important than a gut reaction as to its “coolness". The very idea that cool sites might be better than more usable but drab ones is central to the work of usability practitioners. After all, no amount of painstaking work will compensate for having a site that just looks drab (and if so, should Jakob Nielsen beware?)

Analysis

My reservations about the paper comes from 3 different areas.

Measurement scale

The first is the measurement of the 50ms condition in the third experiment. The other two experiments examined the stimuli with an exposure interval of 500ms. The third experiment correlated responses between a 50ms and a 500ms condition while introducing a new measurement scale. Earlier measurements were made using a computer presented line with the only prompts being “very unattractive” and “very attractive", each at a different end of the line. The third experiment introduced a 9 point scale. Although there is nothing strictly wrong with this, I would prefer to introduce only one new element to a new experiment. Introducing more than one leaves the risk that there might be a complex interaction between the new elements whereas if all but one element is the same, you can be sure why any difference occurred.

New design

The third experiment introduced a between-subjects design: participants saw web pages presented only for 50 ms or 500 ms. I felt that a within-subjects design would have offered more power to investigate the research question because it would have allowed comparison of the same page by the same person under different conditions.

A respectable interval between the two testing phases would have reduced the probability of demand characteristics (i.e., participants “remembering” their scores from a previous exposure). If the interval was, say, a week, then I would feel more confident of assertions about intra-rater reliability.

Can measurements be made in less than 500ms?

The analysis for this involved collapsing attractiveness responses for each participant across all webpages and then correlating them. I don’t feel too confident about this because collapsing scores (to me at least) should be done very carefully. There is a danger that a lot of variance is removed from the analysis making a Type I error more likely.

If scores are collapsed across pages, it is quite reasonable to expect the scores to lie close to the median or grand mean of all scores. A correlation might be meaningless in this case. The alpha of interrater reliability is not reported. If a within-subjects design had been used, reliability could have been tested with an intraclass correlation which would be more meaningful. Unfortunately, I think that the association between the 500ms and 50ms scores is less strong than reported.

True generalisation?

The authors report work by Zajonc which claims that judgements made at 500ms are reliable indicators of longer-term judgements. I would prefer to see specific evidence of the halo effect on longer term judgements when webpages are concerned. It would be interesting to see what scores participants would have made with a long term exposure. While only anecdotal, I have encountered websites that made me cringe when I first went there, but the content was rich enough for me to override an effect of confirmation bias.

Conclusion

I really liked the first two experiments and consider them valuable additions to the field. It is certainly important to realise that judgements about a website may often be made on the tiniest of exposures. However, I have concerns about the design of the experiment that lead me to reject the claim that designers have to build sites that impress in 50ms exposure. These concerns would be easily wrapped up in a couple of experiments: use a within-subjects design and test intra-rater reliability with an intraclass correlation coefficient; test the relationship between short term (ie, 500ms or less) exposures and longer term judgements made after at least some degree of interaction with the site; and keep the measurement scales constant between experiments.

On the whole though, a good read!

References

Lindgaard G, Fernandes G, Dudek C, Brown J (2006) Attention web designers: You have 50 milliseconds to make a good first impression! Behaviour and Information Technology, Vol 25, No. 2. 115-126.

Hate dialogs, love user interaction?

This article was first published on 1 November 2005. This type of interaction crystallised thoughts I'd had for a long time. It is now commonplace though the first were introduced long before this article so I cannot take any credit for them.

Hate dialogs, love user interaction?

“What’s that? What do I do here?”


If you’re like me, you probably dislike dialog boxes as a necessary evil. I know that they are ubiquitous and appear in almost every application, but still I find myself considering new ways to implement what they do. Here, I propose a different way to implement dialogs for applications that doesn’t use awkward boxes.

Let’s start with a definition of what a dialog box is. A dialog box is a GUI element separate from the main window of an application that provides information to the user, and may (but not always) require information in turn. The need behind them is important: programs will
“I have to go back - can I keep the dialog on screen to remind me what I’m looking for?”
occasionally need to interact with a user before an action can be continued, for example, changing the font of a word in a word processor. However, these bits of information are not required often and presenting the communicative components (the bits that actually interact with the user) on-screen all the time wastes screen space.

“Yuck! - Dialog boxes!”

I dislike dialogs for two main reasons.

1. Dialogs interrupt work. When a dialog appears, the user will pause to try and understand what it wants and what they have to do to get rid of it and complete the task they wanted. This means taking time off from their task. A complex dialog can severely affect whether the task is accurately recalled. I have observed and experienced myself how I can forget what I was doing because I was concentrated upon a dialog too much. Reminders such as dialog box titles can help, but they only inform the user as to what their subtask it and not what their main task was. But sometimes programs require lots of information, and that is unavoidable. This is where the demands of an interface should be kept as low as possible; to prevent an interruption that forces recall from long term memory. The designers task is to ensure that the interface presents as little challenge to the user as possible. Try this dialog to see how some designers feel that
2. They are not always but commonly modal - the window from which they came cannot be interacted with. This is a problem if the dialog needs information that can only be gotten from the main window but isn’t visible. In that case, the user needs to consider the information need, memorise it, cancel the dialog, find the information, memorise it, remember the way the dialog was created in the first place, do that action to produce it, remember where the necessary information was supposed to go, remember the required information, and put it where it was supposed to go.

Though this is a long description of what happens, it seems onerous to do this. Further problems arise if the dialog box is overly complicated and more information is required. Then the user needs to remember what is now needed, cancel the dialog, find the information, re-create the dialog, find where the new information is supposed to go, input it, and then input all the information that was required before. This begins to put an unreasonable strain on the user when the user shouldn’t need to remember all this information. Computers are good at recalling information and we should use them for that.
Some dialogs are not modal and allow interaction with the main window. However, modal dialogs are sometimes necessary, but I feel they are used far more often than they should be.

The second point is difficult to deal with - when a program requires infrequently used information, the associated interface will probably be rarely encountered. The first point, however, can be dealt with.

Integrated dialogs

Here is a mock-up of an interface that I’ve worked on. This interface uses the typical modal dialog box and is of a commonly encountered type for a rich text editor. The dialog is a search function for finding text.

As you can see, this is nothing new, but the dialog obscures the content. User can move it of course, but this requires user intervention that is not task related; other things will be obscured too.

The next interface though is of what I call an “integrated dialog". Instead of using a separate dialog box, the interface is embedded into the main window of the program. What happens is that when the program needs extra information, the main interface moves down (gently scrolls, but not too slowly) to reveal the information needed.

Screen space for the main windows contents is reduced when the dialog is on-screen, but this is only for the duration of the dialogs existence. Once the user has provided all the necessary information, the dialog appears and the screen returns to normal operation. This above dialog mock-up is simplified, but the space taken can be increased as needed.

Benefits

What benefits are there of using this type of interface?

1. The main window is still open manipulation. If the user needs to retrieve some information from the main window to complete the dialog, they can just interact freely with the window.
2. The dialog can be completed piecemeal instead of having to do it in one big chunk. This lowers the memory demands of more complex dialogs.
3. The dialog remains on screen when the user is retrieving this information. I have sometimes seen users re-create dialogs just to refresh themselves of the information needed to complete the dialog.
4. Coloured guides can (if relevant) point to and remind the user of what part of their content is being manipulated. For file dialogs, they will not be needed, but for changing the font or style of a piece of text, this information can remind the user of the content which might provide cues as to the context of their task. This will help the user recapture their task if it is forgotten.
5. Only a relatively small amount of screen space is used, possibly less intrusively than the normal dialog because it uses the width of the application.

There are situations when such a dialog should not be used. The most obvious is when the program demands that the user not change or view the contents of a screen; the second is when the dialog requires a large amount of information from the user and too much screen space would be taken. For the second one, it may be better to break the dialog into separate pieces or find some other way of getting the information from the user.

Conclusion

Computer programs can perform complex tasks, but these in turn have complex information requirements from users. Interfaces that elicit this information from users may have to be complex, but reducing the cognitive load to the user can often be beneficial to the user completing their tasks.

Web usability - non relevant links

This article was first published on 5 August 2005.

Web usability - non relevant links

“The road to hell is paved with good intentions", or so it is said. Perhaps the saying should be,"dissemble at thy risk, for blindness is not contagious".

Okay, that’s the arty-nonsense out of the way, but the thesis of this article does strike me as one that is becoming increasingly relevant. When I use search engines, I expect to get a list of documents that may (or may not) answer my concern. I’m experienced enough at using search engines to know that I will likely encounter pages that I don’t want or need, but that’s okay as long as I can access pages that I do need.

The problem is though that finding information that I need can sometimes be harder than it should be because lots of folks out there want to help me. Or rather because they think they have a great business plan that just stops me from doing what I need to do.

Try this: search for a shop that sells computers in Cardiff. I’m interested in what search terms people use with which search engines. Feel free to leave a comment if you want describing what you did and what you came up with.

I’ve tried the same thing myself. By coincidence, I live near City Road in Cardiff which has more computer shops than just about any other road in the city. They are all within easy walking distance of me, though not too close so it can be a hassle for me to go out and wear out my shoe leather.

So instead, if I want some computer hardware, I turn to a search engine and enter “computer shop cardiff". The problem I have is with is the responses that Google responds with (as I said, I’m interested in what search terms other people would use using other search engines, so enter a comment if you want).

What I get are pages and pages of directories, often designed to offer access to “local” facilities, shops, businesses, etc. These are not much use to me: after all, consider the logic. I go to a database of possible websites, enter a search phrase and receive back… pages from other databases.

These directories wouldn’t be such a loss if they actually had links to the websites of the shops, but they rarely do - most often an address (which I know) or a telephone number (not much good on a Sunday when I usually browse for this kind of stuff), but not a website address.

This is not good - I know for a fact that these shops have their own websites. I’ve been to them before, but I never bookmarked them anywhere. While I can locate just about anything I want for my academic work, I cannot find the website of a shop just around the corner!

Craig’s List is a bit of a commercial success story and best of luck to them. The problem as I see it is that many are trying to copy the idea to see if the Craig's List implementation could be improved. If you do have a “local"list of businesses of your own, please remember that not everybody is after just addresses and telephone numbers. Try to offer value , maybe like reviews of local businesses or facilities. If the public won’t do them for you, go out and try yourself - after all, the businesses are local aren’t they? Even just a telephone call with a slightly awkwards question can give you some insight that you can pass on to your hopeful readers. The important thing is that you must offer something useful to people. Don’t try to hold on to customers by having them click through pages only to encounter the same useless information time after time. The best websites are those that offer something of value to their customers. If your content is good enough, they will come back and keep coming back to you. If it isn’t, they will all (eventually) just walk away.

Just don’t try to be the next “Yellow Pages". It’s already been done and there are already too many people trying to catch the boat that has already sailed.

Designing for Amnesia

This article was first published on 5 August 2005.

Designing for Amnesia

Here’s an idea: software’s usability is measured with reference to its effectiveness, efficiency, and user satisfaction (ISO 9241). Simple and straightforward stuff that every usability person should know and much can be inferred from running even just a few observational studies - sit the users down in front of a computer, tell them to do a particular task, and watch them make mistakes, maybe get them to complete a questionnaire with a Likert-type scale. As an aside, I’ve always been wary when no mistakes are made by the users. It either means that the users are too familiar with the software, or that the task wasn’t hard enough. Don’t forget that there needs to be a bit of a challenge in these tasks!

But this makes me think of problems with observational data. Yes it is argued that they possess a high degree of ecological validity (in other words, they are quite realistic tasks), but they are not real-life. Because putting camera’s in work places unknown to the staff and observing them that way is probably illegal - don’t do it! - and hard to control (just when you want them to perform a task, say editing a document, they may go off and have a cup of coffee or a natter.

Information Overload

But a recent article showed that many workers are constantly interrupted from their work with emails, ‘phone calls, meetings, and who knows what other demands leading to cognitive overload (called “information overload” originally by Jan Noyes). And of course, if somebody is in the middle of doing something, such distractions can cause delays as the person tries to remember a) what they were doing, and b) how far they had got before they were interrupted. Sometimes, important knowledge stored in short term memory may have been forgotten completely. This is not good for effectiveness, efficiency, etc.

In a worst case scenario, the user will completely forget their task and have to begin again. At best, the user will have enough information available to continue after giving themselves a short recap of what they were doing. Both cause a slight delay though the latter is acceptable and the former intolerable.

If workers are interrupted so much these days, should designers change tack? Instead of assuming that users have a nice task to sit down and do until completion, should we assume that at any point they might be fatally interrupted? (by “fatal", I mean fatal to the task, not the user!)

Considering users to be amnesic would help us to model the effect of interruptions upon task completion and therefore the integrity of the interface.

I’m thinking that maybe we should consider users to be mildly amnesic rather than fully switched on professionals dedicating their lives to the task and nothing else. Considering users to be amnesic would help us to model the effect of interruptions upon task completion and therefore the integrity of the interface.

So what is amnesia?

Amnesia is a condition where people have problems using their long term memory. Information they learned when amnesic is not available. It may be due to reasons of encoding (in which case the information was never there to be remembered) or decoding (the information could be remembered, but cannot be accessed). Personally, I think that decoding is most commonly the responsible bit - people with amnesia (complete long term memory loss after a traumatic event) sometimes can learn new things but not in the same way as non-amnesics (that’s you and me). The information appears to be procedural rather than episodic, takes a very long time to learn, and doesn’t appear to be available to conscious access.

Designing for Amnesia

But consider designing an interface. A person with amnesia will be told of a task and will begin to execute it after an appropriate amount of planning. However, there is a good chance that when performing an intricate subtask, the main task will be forgotten. I’ve been in this situation myself from time to time and it’s annoying ("What on earth was I trying to do?"). If we design for amnesia, we can offer enough information within the interface to remind the user of their task. Reminding them of the context is a different matter though and is probably not possible. Consider: if my task is to write a letter to my bank manager, I begin by finding out his or her address and then typing this information in (at least, that is the way I approach it). If I was amnesic, I might forget my main task just after I had completed my subtask. I sit there trying to remember what I was doing, but the interface only tells me that I was writing a letter to my bank manager and nothing else. Without explicitly informing the machine of my task (itself an interruption), the system can offer little clue as to the task context.

Systems already provide some information: for example,, dialog boxes have titles that inform a user of the task they have selected, but can be useful to remind them of what they were doing when they return to a task.

If we design for amnesia, we can offer enough information within the interface to remind the user of their task.

However, the benefit of such a system is that it offers room for the user to open a dialogue with the machine (note spelling: I don’t mean “dialog box", but “dialogue” as in discourse) to help them perform their task. The real benefit is that with contextual information, a user could have all the interruptions in the world (even a years holiday), come back and recover their position without too much trouble. Even somebody else could sit down at the machine with no knowledge of the previous user or the system and could yet understand what was meant to be done. In terms of collaborative working, this system would be very useful indeed.

I see the future of systems as being able to provide a rich enough level of detail for any user to be able to infer the original context of the task. However, this information is placed firmly at the subtask level. You might remember that you were saving a document called “letter to bank manager", but does that remind you exactly of what you meant to say? It can help, but it’s no guarantee.

And how to do this

The problem is that many tasks have a large history which cannot be readily put into a nice and neat summary. The information required to accurately infer the original task’s context may differ from person to person, but is there is likely to be a core of information that will suffice for the purpose.

I would guess that the history of tasks by the user would be the most ready way of providing contextual information. Problems will arise when the person multi-tasks as different subtasks may not be related to each other and is hence misleading information. However, the history of actions may be a useful way of doing this. I think I will do an experiment to see what a person can infer from a web browsers history list and see if it’s possible to infer a real-life task from historical information.

Initial results will be published here. Assuming of course that I cannot find any other studies on this topic! Leave a comment or email if you can find anything.

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

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

Enterprise UI Design Patterns - Part I

Enterprise UI Design Patterns - Part I

This is in 3 parts:

Enterprise UI Design Patterns - Part II

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.

Go to Enterprise UI Design Patterns - Part II

Advanced Search

This article was first published on 13 June 2005. It's interesting to see that information retrieval as a topic has recently got itself fashionable again with the rise in big data and natural language processing considering that many thought search was a solved problem back then.

Advanced Search

I read about an interesting project called Aquaint the other day. It is partly funded by the CIA and the NSA and concerns information retrieval. The project is in response to the weaknesses of the current methods of searching for relevant information. While it is very possible to use Google to find just about everything, it is not all plain sailing.

Misleading Information

For one of my experiments, I had people create their own concerns (information needs) and queries to get information about them. Using their information, I found that approximately 50% of searches will produce some information of relevance. However, the percentage of completely relevant information was much lower (under 29%). This is still a reputable figure considering the billions of irrelevant documents that a search engine like Google catalogues.

However, when trying to satisfy a complex information need, the majority of work still lies with the user and not an automatic system. Current search engines are superb for answering simple fact-based questions (such as “what is the height of Mount Everest?"), but trying to understand complex issues that are only covered by a multitude of disparate documents has little solution outside of humans working hard.

Information Overload

I would guess that the NSA and CIA want to be able to trawl through massive databases of information and from that derive useful knowledge (such as a sudden gathering of terrorists in a US city). The amount of information being conveyed across the planet is just too much for humans to cope with, even if systems such as Echelon provide enormous amounts of filtering. Certainly from my own work, I become acutely aware that relying on automatic (read: simple and relatively stupid) methods of dealing with large databases of information was going to present a problem. Most information needs are not simple but are very complex. What is submitted to search engines is often just a small part of an information need, broken down to make the task more manageable. A system capable of addressing these needs would be very valuable indeed.

So how does this system work? From what I can gather, a lot of the work lies in classic (and currently very unfashionable) information retrieval. NB - I say it’s unfashionable because most attention is focused upon interactive search in HCI rather than plain retrieval.

The first problem is having the system understand what it is that the user is searching for. Already, there are good tools to facilitate this task (such as categorisation systems, query expansion), but there was one tool which piqued my interest: contextual interpretation.

Inferring Context

The presence of keywords in the snippets encouraged the user to assume that the document was more relevant than it actually was.

My own research indicated that understanding the context of what or whoever is being interacted with is of prime importance. Certainly, humans, even when they generated their own searches using areas that they were familiar with, made mistakes when context was misunderstood. For example, take Google’s text snippets (the 2 lines of text with keywords embedded in bold characters). These are a traditional feature of the Google interface, and Google is unlikely to ever change them. However, I found that if the document was not relevant to the concern (and at this stage, only the user can truly know this), the user often inferred the context wrongly and selected what turned out to be a non relevant document. The presence of keywords in the snippets encouraged the user to assume that the document was more relevant than it actually was.

Without being able to adequately understand context, searches are always going to throw up non-relevant documents. The problem for search engines is trying to understand the users’ context from just a handful of search terms. Even other humans cannot do this with any degree of accuracy, but search engines can be phenomenally incorrect sometimes.

As an example, if I want to read a review of a digital camera, I can enter the word “review” along with the camera manufacturer and the camera’s model. However, the returned documents almost always consist of online stores trying to sell me the camera, but with very few reviews - the object of my exercise. This is because the word “review” appears often on many pages, but there is no relevant content to my task there. The search engine doesn’t know this and (currently) cannot, so I am left ploughing through many pages of returns to find an objective review.

in and of itself, they can make an accurate assessment of whether the information is relevant or not. The problem remains though of simply having too much information to realistically be sorted through even by a large team of trained analysts. A system that could accurately understand the context of the information need would reduce the dependence on human supervision, but the reliability would need to be extremely high indeed.

Concluding Thoughts

Personally, I think this is an enormously ambitious project and I truly wish them the best of luck (indeed, if I could help I would like to). However, the resources required to tackle this task would be great indeed which I am only too aware of (my Ph.D. addressed only a couple of aspects of this project and then so much simpler as to be unrecogniseable in operation).

Just as speculation, I guess that if the human operators and the system they use understand each others context perfectly, a very effective information retrieval system would be feasible. Indeed, it would also indicate the start of true human-computer interaction.

Is “good enough” good enough?

This article was first published on 23 May 2005. This article is a view from the trenches way back in 2004-2005 and paints a pessimistic view. Since thing, things have changed to the point where effective UX is now seen as a competitive advantage; but lower than necessary emphasis on design still leads to the same design disasters.

Is “good enough” good enough?

In 2004, I gave a brief talk about usability research methods at a conference. In the audience was Jef Raskin, the man who played a significant role in the development of the MacIntosh computer. He asked me a question (apologies, I forget the exact wording) about how interface developers should insist on the best possible interface as an ethical standard. I replied that it was important, though the importance depends upon the task: airplane cockpits should have unimpeachable standards, whereas problems in (say) word processors may be tolerated more easily because there is less chance of the loss of life or health.

However, many large companies employ user interface people and yet produce interfaces that are substandard. For example, Microsoft and Apple have both sometimes ignored their user interface guidelines when releasing their own applications. Disregarding the effect that it encourages third parties to do the same, I often wonder at what level is a substandard interface just “good enough” to be considered acceptable?

Consider: I find many things about many operating systems to be substandard, and yet the product continues to be widely used and even dominant in its field (Microsoft Office, I’m looking at you!). As an example, I was training on MS Project last week and there is only one undo. For an application whose results can be completely altered with a single, simple change, it seems difficult to understand that only one level of undo was available to the user. This was the latest version of Project that we were using, and this is the year 2005.

Despite this, MS Project appears to be the de facto standard, though this is not a good enough reason to tolerate potential problems like this in my view. Even with such glaring usability omissions, how does something like MS Project get to be number 1? Why do people continue to hand over money for applications with substandard and potentially harmful interfaces? There is much to say about MS being a large “reliable” name and safe for tech-wary bosses to throw their money to, but many users tolerate Project and indeed often extoll its virtues.

At some point, the interface must have a minimum standard of acceptability, and this standard is inevitably going to be less than perfect. I guess I’m curious as to how this minimum standard is going to be defined, and I would guess that a number of factors lie behind it.

1. Existing prevelance - probably the most strong factor. If it’s widely perceived as the number one, people will buy and use it. The stronger the prevelance, the more likely it is to spiral into a self-fulfilling prophesy.
2. Backing - the backing of a company like Microsoft is important for many managers. Some will not consider a different companies software without first checking whether MS has a version already.
3. Third party support - the provision of support by third parties (for example, in training needs) is very important and possibly the biggest drawback to open source software: how does a company organise training for OpenOffice.org compared to MS Office? This is no criticism of open source, but rather a reflection of how third parties support the safest bet.
4. Interference - this is the controversial usability aspect. The task is important enough to be completed, and drawbacks in the interface are not sufficiently bad to deter a user (though they might well be frustrated and annoyed by it!).

It seems then that people are willing to tolerate applications that are less than efficient, and even when they are not the most efficient solution in the market. At some level, the returns on using the application are seen to outweigh the perceived problems. Sadly for the field HCI and usability, this means that effort might be best placed in trying to develop an interface that is not perfect, but rather just “good enough". This will depend significantly upon the company and how much market share its product has.

I feel saddened somewhat by this: that people really do prefer to satisfice than satisfy when it comes to interface considerations. Given that UI people are the first to go in cutbacks, my recommendation to anyone interested in the field is not to bother. Train yourself as a plumber: people always need clean water.