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.

“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.

Do Users Want, Need or Desire A Startup Sound?

Couple of quick ‘hmm that’s interesting’ links. Firstly, related to my Vista post the other day, here’s a short NPR piece on the new Vista startup sound. They only get to the nub of the matter towards the end of this clip so I’d be really interested in other people’s opinions on auditory feedback in interfaces. It’s not something Tjeerd mentioned last week but it’s clearly something Apple take seriously too …

Secondly, I’m always a fan of Marc McNeill’s posts over at Dancing Mango (etymology of the title?) so was delighted to read the ‘needs vs. wants’ item last week. Coming as it did on the back of Dan’s UX2006 session which had already got me thinking more profoundly about personas, this post is a good reminder about interrogating user motivation. Some of the comments it has received are a little rambling but worth reviewing all the same.

User Experience 2006, London, “User Experience Documentation”.

It was inevitable that I’d want to blog about my session yesterday at the NN/g ‘conference’. What is unexpected however are the amount of thought provocations that I noted down throughout the day with little ‘Blog’ tags attached to them, some of which will end up as fully-fledged posts, others of which are, on reflection, nothing more than idle guff.

I’m glad I chose not to lug a laptop into the city and thereby blog on the day, and I’m even gladder that I took the preliminary letter’s advice to wear several layers too; the room we were in at the Millennium Hotel in Gloucester Road was borderline Arctic during the morning session. Not that that seemed to bother the extraordinary amount of Scandinavians that seemed to be in attendance. I still do not know whether their predilection toward User Centred Design is the consequence of having a Scandinavian guru at the helm (Jakob) or whether it is simply one of those accidental cultural niches that seem to develop. Either way, they were there in numbers, speaking embarrassingly great English and having a justifiable confidence in their abilities. The second largest group of attendees seems to have been the BBC. Looking down the delegate list, I would suspect that half their ‘new media’ department were there in one form or another.

I was there to learn from Dan Brown. An erudite New Yorker (now resident in D.C.) with a dry wit and a decent book to promote. We were a tough crowd, not because anyone was particularly controversial but because despite his attempts to lighten to mood with references to his experiences as a proud new(ish) father something was getting lost in translation and our continental delegates seemed more keen to read ahead in their slide packs. For the record, I thought he was a solid and amusing presenter and frankly when you are dealing with a subject as potentially dour as sitemaps, flow charts and wireframes then any smattering of humour is appreciated.

Dan’s approach has been to simplify web development documentation into ten key deliverables split by ‘User Needs’, ‘Strategy’ and ‘Design’. In the session at User Experience 2006 we looked at personas (user-need), sitemaps, flow charts and wireframes (design). As always, the best way to learn is through a combination of practical exercise and demonstration of the good and the bad, with appropriate discussion around the same. Within fifteen minutes of the session starting, we were already in and creating personas. This was absolutely the right thing to do. As we picked these apart, we progressed through what must have been a cathartic therapy for Dan as he displayed a healthy portfolio of confusing diagrams, schemas and flows from his past, this was a theme persistent through the rest of the day. Dan’s honesty in showing ‘hyperdocumentation’ (by which I mean diagrams and data visualisation on a large and complex scale) from his own collection was a compelling insight to the workings of a man who’s mind he freely admits craves the release of encapsulating his thoughts on paper and on file. Many of his examples showed an exquisitely sensitive use of colour and design to convey a wide range of attributes. A document that seemed inaccessible at first was presented gradually until it made complete sense.

He was challenged repeatedly on his intentionally inconsistent approach to documents (ironically it was internal document inconsistency that prompted me to attend the session) and his response was considered: no two projects are the same; no two audiences for those documents are the same. Bear in mind at every planning stage for your work those people who will be reviewing the document, and the document’s purpose. It seemed that there is no need to slavishly follow a given set of rules (e.g. that personas must show x, y and z and that sitemaps should be formed of boxes and arrows) if the document’s purpose can be communicated effectively without doing so.

Before I attended the conference I blogged that it was expensive and that you have to pay for the privilege of learning from the experts. In Dan’s case and, at the risk of sounding sycophantic, I am glad The Company paid up because it was worth every penny.

I’ll be returning to the themes of documentation and providing examples of my own styles in the next few weeks. Tomorrow however I intend to run through some examples of User Experience tweaks in Windows Vista following Tjeerd Hoek’s plenary session demo at User Experience 2006.

Finally, quick hellos to some people I met at the session: Tero Tikkanen (Vaisala Oyj, Finland) and Nick Pleydell-Pearce (Global Beach [yikes! flash only site], UK)

:: Update with Dan's slides originally posted on slideshare which contain the examples not in our take-out packs.

User Experience 2006 Conference: What I expect to see/hear...

I’ve booked myself in for a day at User Experience 2006 on the 8th November to take part in Dan’s documentation session. As with most things NN/g you have to pay for the privilege of dealing with the most well-known and popular user-centric consultants so I hope I, and The Company get value from the session. (UPDATE: See Web Analyst, apparently John Boyd's session in Seattle left some people wanting)

Having been fortunate to have taken degrees in psychology and information processing I feel that the science behind UE is a given. Where I have had issues in recent years has been in converting my academic reporting and methodologies to corporate environments. A director doesn’t want to read a journal-formatted paper and it’s rarely appropriate to approach each project with academic rigour when the focus is on the baseline. Furthermore, your colleagues haven’t all come from the same background and so working together produces discrepancies in documentation and techniques.

The intention is therefore to consolidate my experiences to-date and emerge from this session with a standardised set of deliverables for real-world projects. Deliverables which will inform and empower the decision-makers and clients surrounding our projects with comprehensive data, insight and solutions.

Later on in the day I’m hoping to attend the session on Windows Vista. I think we have problems sometimes dealing with disparate teams across locations and so on but read this:

"...[the talk will cover] the challenges and ultimately the successes the user experience team achieved in driving product innovation and quality, despite their working in a largely engineering-driven culture, and having to collaborate, over five years, with several thousand people across multiple divisions at Microsoft Corp"

Crumbs. That's scale!