Buyers aren't always users

At The Company we've just been introduced to a new expenses system. This system for raising personal and business expenses has been deployed to replace the ageing paper-orientated process that existed before it. The old system necessitated the completion of an Excel sheet which was then printed, receipts attached and sent to Accounts Payable. The problem was that these were invariably untraceable. However, as an end user-experience it was pretty straightforward: use the most up-to-date template, complete, print, sign and send.

The new version is horrendous. This clunky piece of enterprise software (HRMS) sits on a preexisting bit of Oracle kit which manages a host of HR operations. Everything from logging an absence to checking your payslip and updating emergency contacts. For reasons of confidentiality I can't show you screens sadly but suffice to say it is a complete dog's dinner with some of the worst usability I have ever encountered. What's more, the launch of the new expenses system was preceded by a compulsory Flash-based training program. What's that old adage "if it needs instructions, it doesn't work" ?

I'm not denying that the old system needed reform to ensure service levels, audit and security were improved but at the expense of the end user?

What this exposed was the general piss-poor quality of enterprise solutions. Jason at 37signals' blog, Signal vs. Noise, posted a timely article today based on Khoi Vinh's Subtraction piece which highlights and tries to explain some of the failures of the expensive solutions. Essentially the suggestion is that it's not the end-users that are specifying, buying or deploying this junk, it's aspirational senior management who have been persuaded by a round of golf, a night at Spearmint Rhino and a good price to buy what's on offer.

I really wish you, and the people that buy this stuff, could actually see the end result. In a tight, cost and efficiency environment where every member of staff needs to behave as if the business was their own it would do these buyers good to understand the value of their purchase; As Jason so succinctly puts it: "There’s no camouflaging value when the buyer is the user".

(Oh, and we're forced to use Lotus Notes too, but don't get me started on that.)

The Pervasiveness of the Web

Interface orientated blog Functioning Form have used a recent NY Times article to highlight a seep of web-orientated design onto traditional media. Observing rolling news channels and interactive TV offerings certainly shows a similarity with web layout. And not neccessarily for the better. Do we, for example, really benefit from ticking news items below the moving image? Well possibly we do but once you start adding weather data, traffic reports, time and date information, the channel and show identities and possibly a picture-in-picture you have really crowded the real estate.

Where these screens work are in silent environments. The gym, a foyer or reception or at a transport terminus (Liverpool Street sation, London pictured) where sound is muted. Then the moving image becomes semi redundant and the surrounding data (clutter) becomes the focus.

By contrast, the traditional viewer who is able to hear the sound is increasingly distracted, particularly if the story is cognitively challenging. Part of the explanation here may be due to the evolutionary psychology and the way we perceive the visual field. Our high resolution focus is limited to small cone (foveal vision) - items on the periphery (rod cells) of our vision are in low resolution and ignored until they move. Useful for spotting a predator sneaking up on you when you're focusssed elsewhere, also particularly distracting if a peripheral banner ad is blinking on a website or if a news ticker is scrolling on a TV screen. This triage of information is something we should respect, not attempt to interrupt for attention*.

Anyway, back to the main point. High-contrast visual displays and interactive TV programming is apeing the web. Even newspapers are starting to look more web like as online newspapers become less print-like. The trouble is, some of the bad interface stuff is making its way onto this old media.

* - caveat: I realise that distant high-contrast displays like those at train stations are sufficiently far from us so as not to be as profoundly affected by the strength-weakness of foveal and peripheral vision as you might a TV or TFT screen, indulge me.

smorgasbord-design ... three months on

Facebook had started to take over my web time until a week or so ago when I realised I'd not done anything on Last Chance Saloon for a while. Then I realised I'd not posted our wedding website yet either. Then it became clear that I was falling behind on the stuff I actually get paid for too. But frankly that doesn't seem to matter as regardless of how far I fall behind on that stuff, the other people who'll plug it all together behind the scenes are even further behind and even more under-resourced than I am. So where to focus my attentions?

Well, the invites went out for the wedding and since then it's been a bit of a whirl of RSVPs, sorting out groomsmen's attire, stag events (thanks Robin), website stuff (Marisa and I are getting there on that) and more. Floristry and church arrangements seem to be a never ending saga with the former causing the most headaches both financially and logistically. I'm sure we'll get there in the end but it's hard to think that I'll not resent the money and hassle on the day when I look around at all the hours of work and £s of cash that have been poured into it all. It's all well and good starting the whole wedding process with intentions of project managing the whole thing to within an inch of its life but it's another thing when you reflect on some of the principle reasons it was never going to work that way:

1. I'm not a project manager. In fact I'm not even half a project manager. I'm a thoughtful creative type who's easily distracted.
2. I no-longer live with my fiancee and, worse still, I live 3hrs away in Norwich.
3. My fiancee couldn't be less interested in the whole affair as she's got bigger fish to fry throughout the courts of England now.
4. Two years of intermittent planning enthusiasm is enough to stall the momentum of the best laid plans.
5. Financially it's all become so obscenely expensive that the scattering of luxurious touches has just been turned into paying someone a King's Ransom to re-arrange the deckchairs on the Titanic.

That said, there are moments of brilliance. The band, the invites, the reception venue, our enigmatic priest, my shoes ... so I'm quite sure it'll become more than the sum of its parts. I only hope SWMBO's employers let her have the day off now to enjoy it.

Wedding aside, Last Chance Saloon is careering along at a pace. A frankly bewildering generosity from the many nooks and crannies of The Company has ensured that much of the expense for our ludicrous project to drive to Rome in a tired old Volvo has been borne by generous benefactors. Some creative writing, a smattering of mediocre photography and a few long train journeys to Surbiton have resulted in an update this morning which starts to reveal more about the direction we're heading in (predominantly South West after we pass Paris).

The lack of a commute (Shank's Pony now gets me to work in under 5 minutes) has killed off my inspirational out-of-work thoughts around user experience and the intensity of the laborious projects i'm engaged on at work has stiffled some of my much needed thinking time. In a desperate attempt to nod myself back in that direction I have resolved to pick up listening to IA podcasts and have been networking on LinkedIn as well as joining the Information Architecture Institute to try and become part of a wider knowledge sharing community.

My intention this week was to write a lengthy piece about why Facebook has captured the imagination and web-time of millions of people who never before would have considered signing up with and dedicating time to photo-sharing, blogging and general social networking. Why, for example, is Facebook's growth causing people to peel away from Friends Reunited and MySpace in droves? I think I know why and, if you're lucky and I start to find some time amongst cars, weddings and work, i'll explain all next week.

Documenting the user interface

I recently spent an hour explaining to a potential colleague what it was that our team do. I’ve discussed this recently partly in reference to a recent Design Critique podcast but, as this particular person is closer to our business, it was possible for me to dispense with the coffee shop analogy.

Instead I chose to trawl through some of the documentation I produce. Since taking Dan Brown’s tutorial at User Experience 2006 and reading his excellent book I’ve become a bit of a documentation junkie to the point where the documentation is clearly overkill for certain smaller jobs. So I thought I’d take the opportunity to show off some of the styles and approaches I’ve adopted.

I tend to start with personas, which, as any number of user-experience articles will tell you, are a foundation stone for understanding how users interact with a system. This involves defining a group of users (generally from research data), building demographic profiles, and understanding their needs and motivations before sketching out the scenarios in which they might find themselves. I present each of these in a summary page and detail page . I am not a huge fan of using photographs to illustrate personas as I think the audience dwell on any physical appearance, so I have borrowed from Loz Gray’s work and introduced iconographic representations. These have the added benefit of being race-neutral and re-usable for various ages.

Having produced these, the next step in the process is to define a sitemap. The sitemap, such as it is, has a limited lifespan. In the next few years I doubt we will see many produced as the web moves away from individually coded static pages. Sitemaps do a great job of representing hierarchy, taxonomy and the long-view of how things fit together but they don’t really give us much insight into how, for example, a complex dynamic service application or something like Google Maps works. More and more I find myself representing stacks of pages in a sitemap rather than individually referenced HTML documents.

That said, in the absence of producing something more ambiguous, like a conceptual model, they are churned out continuously here at The Company. If I am honest, they are welcome relief for me as I am not a great fan of the chore of creating personas and prefer moving around boxes and arrows. I think this can be seen in the detail of my recent sitemaps, which present a considerable amount of information to the build team, the content developers, and the information architects.

For example, this blow-up detail shows the relationship between pages (connecting lines), their hierarchy (top down), their category (blue background), whether they have had content produced (green circle), where they are hosted (colour of title), their reference number (top left of box) their wireframe type (top right of box) and, of course, their title (centre). In other pages, not shown in this detail, I have used the bottom left corner to indicate whether there is any embedded video on the page.

Granted a sitemap like this has gone through much iteration as the project moves through the design phase toward build (hence there are references to wireframes and content) but to me it shows the level of detail to which one can go whilst maintaining an accessible document. The classic example of which is C. J. Minard's seminal diagramatic map "Napoleon's March to Moscow".

From the early sitemap we can walk the personas and their scenarios through the screens and map their journey. Interchangeably known as user-journeys, task flows, page flows or scenarios, these documents demonstrate how well your information architecture (as seen in the sitemap) works. Again, I borrow here from Loz Gray and use an isometric style that I think promotes a clear view of the journey the user takes. Flat 3D boxes and arrows don’t really inspire or compel stakeholders, if you put up a nice diagram like this it becomes easier for your audience to visualise the journey and the sense of the user being ‘presented’ with screens. I have used this approach for the last five months across static and active sites, allowing clients to visualise everything from amending personal details to clicking through a knowledge store or finding help. With the shape set now firmly embedded in my Visio toolbox I can drag and drop shapes leading left and right, different arrow forms to represent strong, weak and conditional paths, decision points (an isometric diamond is a difficult thing to draw indeed), error points and just about anything the sitemap can show.

In several instances, the barriers between processes have jumped out at me when presenting them in this format. Missing links suddenly seem even more obvious, lengthy diversions and crowded critical paths are quickly spotted and revised.

The final step in my documentation journey is the wireframe. Having experimented recently with the low-fidelity ‘page description diagram’ approach – which to me is like describing the front page of The Times when a blurred photocopy would have been more effective – I have resolved to stick to medium-high fidelity wireframes. In part this is because I’ve always liked the creative construction side of wireframing. I’d feel cheated having gone to great lengths in describing personas, the sitemap and the journey the user takes only to be produce an ambiguous written description of a screen. A well considered wireframe still leaves the designers with more than a colouring-in job. The designers can add visual prominence, alter sizing and positioning and consider complimentary form and colour. What I feel the information architect’s job is to do is to say ‘here’s how the page should function, this is where they should look for x, this is where they will find y and these are the relative levels of prominence’. It is less prescriptive than the building architect’s blueprint but considerably less ambiguous than saying “the room in this house should have three windows, two electricity points, a wooden floor and four brick walls”. So, my wireframes show text placeholders, pseudo-latin text, layout, order, scale, complexity and also contain build or dynamic element-related annotation.

I’m pedantic and fastidious about version control and document referencing. All my documents are peppered with notes about page and document versions, titles, page references, disclaimers (“Wireframes do not represent the final design…”), client names, contact details and relevant key/legends. It is crucial when so much documentation is floating around that we have a clear view of what it does, who did it, for whom and when.

I hope this has been an interesting read, please do get in touch (john at smorgasbord dash design dot co dot uk or in the comments) if you’ve got examples of documents you produce or alternative approaches to this kind of stuff.

Information Architecting The Coffee Shop

As a user experience architect I often get asked what it is exactly that I do. A learned friend once explained to me that if you can’t explain your job to your mum then there’s something wrong. I never understood whether this meant there was something wrong with my mum, my job per se or just the title but either way it’s time to address that very issue.

I think I feel that my job is more of a re-labelled Information Architecture (IA) role than anything else but that’s even more ambiguous. Plenty of people have tried to define IA, notably Rosenfeld & Morville (“Information Architecture for the World Wide Web”), Wikipedia and recently, Tim, Tom and Chris Farnum. Having recently discovered Indexed I’m in a bit of a ven diagram mood so I’ll borrow from that and the Design Critique podcast to visualise IA as follows (left). I think this encapsulates what we as IAs try and do, to balance the three (oft-competing) requirements of users, the business and the content we have to organise.

You’ll notice that this definition isn’t tied explicitly to the web. It’s a model that covers all kinds of information interaction and whilst I could sit here on a blustery January day and bang on about web-based IA I think it’s time to talk coffee. It’s quite a good analogy I think for real-world IA, where non-web people can get a feel for what practitioners like myself do.

I occassionaly find myself in need of a new place to go for lunch or for coffee. In Norwich this isn’t easy to do, it’s fair to say I’ve tried most of the sandwich bars and decent coffee shops and what strikes me in the same way it does in towns up and down the country, is the organisation and presentation of the menu board. In London these places tend to be quite busy at lunch with a healthy queue in most places giving you plenty of time to look up and read the menu while you wait. In Norwich there’s not so much time, you’re asked for your order within a minute of entering the shop and if you’re new to the place that’s not enough time. Part of the problem is the bewildering array of choice. Lame stand-ups (and my Dad) regularly joke about the ‘I just want a coffee’ situation when walking into a Starbucks but, coffee aside, sandwich shops like O’Briens have a range of sandwiches, toasties, panninis, ciabattas countless hot and cold fillings, salads and soups. I like variety in my life (!) so I want to try something different and will scan the menu boards looking for combinations, unusual fillings, relishes and breads. This takes time and it’s not helped by poor information architecture.

If I was re-designing a menu board to improve customer journeys in a sandwich shop or coffee bar this is what I’d do:

:: Prioritise. Order the most commonly requested drinks/sandwiches in a section of perhaps 10 items on the far left of the board. Most people scan left-to right and would hit this section first. I would use till data to define the top requested items and order them accordingly. The only risk here is that this is self perpetuating, new people come in an order the same things everyone else does but the trade off is that they’re likely to come back and their natural boredom threshold will encourage them to explore other options later, particularly if the alternatives are promoted successfully…

:: Structure. Group similar items, all the hot food items in one group, cold in another. Then sub-divide, meats, fish, vegetarian. In each subcategory, order these by price, most expensive to least. If there’s a consistent pricing structure, promote it: e.g. bacon and cheese sandwich £2.50, toasted £2.90, think customer journey. People come in and decide first what type they want: sandwich (brown, white, granary), baguette, panini, soup or ciabatta (olive, sundried tomato) first. Then how they want it: hot, toasted, plain then filling. The menu should reflect that from left to right.

:: Display. Use a clear and consistent typeface. Have bold headings, use colour sparingly and intelligently (‘Hot Food’ in red for example), don’t add illustrations. Most people know what a cup of coffee looks like, or what a baguette is. Position the board high and use as much space for it as possible. If your bar has two entrances or queues, have two boards. Consider having a second smaller version close to the till. All too often brand typefaces are used that are fine for the shop logo, napkins or coffee cups but don’t read well from 5m away and 3m below. Use space, less is more. Listing every possible combination is pointless, especially if all your fillings are displayed individually, make it clear they can build their own and promote a few suggestions.

Change it. Be prepared to change the board regularly. When you stop selling lines or start selling new ones, adding them with stickers, hand written notes or another board breaks the structure. It’s like a library getting a new book and sticking it on the end of the shelf. It might get found but it’s more likely to be if it’s categorised and filed appropriately. Be prepared to listen to customers and analyse their habits. Are people saying and buying the same things, can they find your new caramel frappuccino or is it that they just don’t want one? Do you only seem to sell salads to vegetarians, do people know they can have their soup in an oversized takeaway cup?

Ok, so I don’t work in the restaurant trade but to me, that’s a good thing. As a customer I know about the problems I have and as an IA I know of some of the ways these can be solved. I’d love to know if Starbucks uses IAs to define its menu boards before the designers are let loose with their crayons and I’d bet that two thirds of small-town sandwich bars write their menu boards by consulting a long list of what they plan to sell.

Take a look at my very quick sketch of how a well organised menu could be set out. I hope this helps to bring IA alive for some people, feel free to feedback either by commenting on this post or emailing me … john at smorgasbord hyphen design dot co dot uk ... P.S. No more posts about coffee, promise.

UPDATE 3 Feb 07: The guys at Adaptive Path have posted about trying to explain what user experience architects do using a few options. Worth a read...

“We wanted no ghost to tell us that”: Acknowledging Our Expertise In Information Architecture.

We’re moving offices at The Company this week and consequently I’ve unearthed some dusty print outs of articles I meant to read. Some of these will end up in blog items in the next week or so and the first to prick my conscience has been a 2002 piece by Jesse James Garret. It was written at a time when jobs were being cut left, right and centre as the ‘new media’ industry euphemistically ‘consolidated’ itself.

With this in mind, it is quite an introspective and defensive critique of the purity of information architecture (IA), seeking to justify the role’s existence. What Jesse James Garret astutely points out is the tendency to justify every decision we make as being supported by user research and testable to within an inch of its life. Personally, I have dwelt on this as someone with a rigorous empirical background in psychology where, if it was not testable it was not truly meaningful. Taking a 'step back' (one for you, Matt) it is worth considering the role of a print editor. When they make decisions on layout, content and indeed the customer journey through their product, they are not doing this based on eight people in a room telling them what they think. They are using their insight, experience and gut reactions. They are doing what they are paid to do – to make tough strategic decisions about what they think is the right way of doing things without having the safety net of user-research to fall upon.

I wish I made more decisions like this. I wish I was able to be more bold and say, “you know what, this interaction should look like this because my years of experience tell me it should”. Too often, perhaps, we sit and listen to customers tell us exhaustively what they want and then agonise about what they meant. To go back to the wants and needs argument that Marc McNeill so effectively summarised recently, how many people would have sat in a focus group three years ago and said they would need to upload video and share it with the world? Not many, but then came YouTube … likewise, who would have thought kids would want to be creating web pages, writing daily blogs and sharing their lives with the world on an unprecedented scale? Not a huge amount but then came MySpace.

Now, I’m not saying that IAs would have foreseen YouTube or MySpace ahead of their users – if we all had that foresight IAs would be being paid a lot more – but it does demonstrate that user-research doesn’t provide all the answers.

If we dwell on making the most usable sites as defined as the sites that pass the user test then we become no better than the teacher who schools their pupils in just enough to pass the exam. The exam in this example is no more reflective of the challenges of life than the user test is reflective of the continued experience of a website by thousands upon thousands or users. The trouble is, testing and metrics deal largely with the quantifiable elements of experience, time taken, click volumes, conversion. Unfortunately these are the predominant currency of business and unless you present such information higher up the chain your credibility is called in to question.

To return to the publishing editor analogy, the editor is top of the tree. Their decision is respected not just because of the experienced opinion but because in the hierarchy there are few people above them. Information Architects on the other hand sit lower down, we don’t have that power and all too often we find our work being passed up the chain, interpreted, interrogated and ultimately ignored as the wishful thinking of an idealist. Peppering a report or proposition with research is our way of protecting our ideas, wrapping them in cotton wool to survive the journey to the senior manager’s desk.

At the end of this journey what lands on the manager’s desk is a collection of research quotes and some proposed designs. What is missing is the insight, the explanation of how we leapt from someone saying they wanted to be able to change their address to a panel in a wireframe with ‘change my address’ on it.

Fortunately the assertion by Jesse James that IA as a distinct role would fade away have not proved correct and in many organisations there exist a team of such professionals. Granted, we have had to broaden our horizons and think about technology and business at the same time but, at our core, we can still be information architects.

Nevertheless the advice still holds true. We should trust our abilities more and occasionally eschew the temptation to commission research at every turn to support our work. We must be prepared to act on hunches and still show our working. Explain and annotate why we have made these decisions but not be afraid to say it was our personal decision and not the decision of 83% of survey respondents. These hunches and gut reactions allow us to work and react faster. Take AJAX for example – we have not had the time to test and research this stuff adequately but we are under immense pressure to deploy it sooner rather than later for the UE and technological benefits. We should be brave enough to generate great interfaces using AJAX implementations based on our experience and get this stuff out there without waiting for XYZ Ltd to fling something out and observing how they get on.

In time, I hope senior management will begin to trust these hunches and – when augmented by the right amount of research – will begin to believe the value of the small collection of experts in their web teams. I’ll paraphrase for my final thoughts: Research data and formal methodologies do not guarantee better architecture. Better architects guarantee better architecture.