Getting Your Website or Intranet Under Control: the Power of Information Architecture

This blog looks at how to direct and control your web application, be it a website or Intranet.  What is often forgotten is that information architecture is fundamental to what a web application is and does: it defines its scope.  A good information architecture meets both business and user objectives by means of a user experience strategy.

Previously, I gave a general introduction to information architecture and I referred to a supermarket website and how you might group things together and label them in a way that users understand.  This is generally a good idea, as long as it’s aligned with business objectives: we have to be realistic here.  Sometimes it’s for the public’s own good because, as i guessed in my last blog, some people (65% according to this BBC article – will just think of meat as meat, cooked or uncooked, and be happy to put them together in a bag and probably on a user-defined supermarket shelf – something of a hygiene factor!  And, as I also said previously, customers (especially parents) would be unlikely to group sweets next to the checkout in a physical supermarket architecture!

So, what is all this about?  Governance.  Like it or not, things need a bit of control but where that control comes from and how it is managed is the subtle part.  It’s an issue both for websites and intranets.  Websites are at risk of being driven by the whims of the Sales & Marketing seniors or, even worse, by the whims of an agency they hire.  Engaging users in card sorting exercises helps to design a structure that makes sense.  Similarly you can validate a site structure – or changes/additions to that structure – with a tree test.  Tree tests are great because it allows the users to truly test the fundamental information structure without being cluttered by the design or layout of your actual site.  This all seems tremendously democratic.  What about those 65% who get things wrong?  Well, the reality is that sometimes the users do get it wrong so in reality you shouldn’t be too literal about all parts of user research such as card sorting and like it or not some stakeholder (steak-holder?) or other will want to find some way of putting certain things in users faces – in a language they may wish to choose.  A compromise is made but objectives for both parties are met as far as possible.

When it comes to intranets then having a good information architecture in place is critical as it provides a validated reason for the structure of the site.  In governance terms it also provides you with good reason not to change it willy-nilly.  One of the greatest problems is that everyone wants a piece of it – “oh could you just add a tab for my product/team on the home page” or whatever.  Sites that give in to those kind of requests become a mess and then become another project, until it becomes a mess again.  In other words, information architecture governance helps you manage change control to ensure that you don’t lose and confuse your users by constantly shifting things around and letting the structure go at the seams.  No one will thank you for letting it go, except the people you bring in to sort it out.

So in summary, a good user experience strategy means good information architecture which in turn means good governance.  In reality, this is the happy compromise between the objectives of the business (that wishes to sell or say things) and those of the users (who wish to find things as easily as possible).  It is critical in not only getting a website or intranet right – but in keeping it right through the process of change control.


Information Architecture for Children, Supermarket Shoppers (and Beginners)

I recently tried to explain information architecture (IA) to my 13-year old daughter.  We’re trying to get our house extended just now so we bore the kids a lot with talk about architecture – so I thought I’d bore my daughter some more.  I’m not sure how well I explained it but I think she got it.  I explained that IA is about organising information in the best way, mainly so people can find things – like on websites.  I then talked about a specific example, a supermarket website.  I said that when you go to a supermarket website you want to find things easily – by looking in the right categories or searching.  To design this right, you could ask customers to group various items like tinned tuna, bananas, apples, cooked chicken, raw chicken, etc and ask them to label them.  You can be pretty sure that bananas and apples would be grouped together in Fruit or Fruit & Vegetables but some people might put all meat together and others would separate cooked meat – for hygiene.  In user experience terms, this activity is called a card sort as this is traditionally done by writing items on cards and getting people to sort them into groups and then provide names for those groups.  There are plenty of online tools to do this now.  This gets the site designed in the minds of the user.  It’s not perfect but it helps you structure information in the most optimal way.  I think that’s about as far as I got before we entered Waitrose to get some food.   We didn’t think on it any further.  Waitrose is a nice customer experience and we’d been shopping there for 10 years (and, however good their website is, I’d sooner pick my own fruit and veg thanks!)

What’s interesting about this example is that with shops you have a hybrid real-information architecture as shops have to decide how to group products in their stores and how to label them.  What’s also interesting is that this physical layout has been dictated to users (ok, shoppers) but they’re so used to it that if you asked them to come up with the categories that they’ve got used to over the years then they would probably replicate their local supermarket (though I don’t think parents would opt to split the sweets and confectionery area and put some of it by the checkouts.)  Does it matter who’s idea it was in the first place?  Absolutely not.  What’s easiest for people is what counts and what’s easiest is what’s familiar.  Convention rules again.  What’s nice about information architecture is that because it isn’t physical then things can be described in more than one way – so salami might sit in the Delicatessen category and raw chicken thighs in Uncooked Meat but both could also be tagged as Meat.

The web already has quite a standardised information architecture that has established over time. You know this because when you go to a website you’ll almost be guaranteed to find About Us or the increasingly fashionable Who We Are.  If you’re looking for directions or a phone number then you’ll go to Contact Us or similar.  There’s little point changing these conventions unless you have a very good reason – some companies don’t make Contact Us very obvious as perhaps they don’t want to meet the cost of being contacted!  IA is also relevant at the page level by having key information displayed in priority or relevant places (top and left), having clear information hierarchy (eg text size and image placement to draw the eye): conventions we know from centuries of publishing.

So, information architecture is critical for websites to be successful: it’s a lot more than just visual and functional design.  IA is also important for information systems and business applications although its use is more mature on the web because companies have to compete.  There’s rarely any competition inside an organisation so only the largest or highly information-based organisations have really grasped IA in a big way.  This is of course rapidly changing as people’s awareness of standards is changing: users won’t stand for a poor user experience any more.  It also becomes more important in an era of record-keeping and compliance.

Net time we’ll get into more detail about how information architecture works, how it should link to business objectives and how it can be used for information governance and settling arguments!

User Experience as Body Language

When designing technological interactions, more often than not, we are designing virtual social interactions.  And social interactions are about communication.  And a key aspect of communication is body language but let’s call it non-verbal communication (nvc) as it’s a bit more inclusive of things like tone.  And communication is conducted by individuals guided by conventions.  And I know you’re not supposed to start sentences with ‘and’ but who cares because it’s a grammatical convention that doesn’t really matter any more and certainly not in such an informal context as blogging.

I’ve previously stated that User Experience Design addresses the ‘how’ as well as the ‘what’ when it comes to system requirements which traditionally focus mainly on what – ie the data, content and functionality in principle.  (UX of course takes this further with information architecture, content strategy, and so on).  If we liken the ‘what’ part to verbal communication then the ‘how’ part is equivalent to nvc, the positioning, the gestures, the tone, even the clothing.  How many systems and websites do we come across that can meet our needs but it’s like dancing with someone who has two left feet or dealing with someone who is socially awkward – like the boys in IT.  I’ve worked a long time in IT which allows me to make mean cracks like that…

Problems in system design arise for two main reasons. Firstly, it’s not a real interaction and most people are not used to modelling virtual interactions in technology to produce something that makes sense. The other, on the web anyway, is the desire for organisations to stand out and be different – and breaking conventions as a consequence.  I once worked on a project with a design agency who had designed a site for another organisation with the navigation on the right.  Interesting, I thought, for right-handers you don’t have to work across yourself.  But that’s nonsense, we mostly read left to right.  And everyone else does it on the left.  It wouldn’t work.  We’re not looking for logical here, we’re looking for understanding.  It’s the same when you see a site or web application with the logo on the right hand side, the search at the bottom, the content not grouped appropriately, the clumsiness of redoing or undoing something, etc.  As usability legend Steve Krug says, conventions are your friends.

The point of the nvc analogy is to always remember how something is conveyed.  Is it clumsy?  Is it awkward?  Can they understand it?  Do people get it?  Should we try it out?  All the usual questions you might ask about, say, a presentation, a best man’s speech, an email, or whatever.  Or is it the abominable ‘training issue’ which you can’t afford online – so dump it in Help/Frequently Unhelpful Questions.  It’s best to try to think of systems as modelling human interactions and to know when it’s time to stop reinventing the wheel.

Why Business Analysis Fails the User Experience

We live in a world of opposites, or at least that is how people view the world. Previously, I talked about those that prefer either traditional, sequential waterfall software development or the more flexible agile approach. You also tend to find two polar opposites in the development of business applications in contrast to websites and e-commerce applications.  IT tends to attract those people that like to work with technology – and not people; whereas Marketing, where the whole point is to engage customers and interact with them, tends to attract those that like to work with people.  Yes there are exceptions but as generalisations they are true; I’ve worked on both sides of the fence and seen the differences consistently.  No wonder then that we find different worlds and tensions.  To get their websites done Marketing would sooner get their own team or outsource to design agencies who know the importance of getting across the right message, or customer experience in the fullest sense. This is all well and good in e-commerce but who will champion the corporate customer, the poor staff member with no choice but to be served by IT even when some of the systems they have to use look like they were designed by children?  We end up with a split between the user-oriented web/e-commerce sites that can delight their users (as well as sometimes frustrate them in their careless execution and lack of attention to detail) and business applications where the requirements are gathered and delivered to in a way that frequently fails to deliver to expectation. Have you noticed that the main difference in personnel is the presence of UX designers on the one hand and business analysts on the other?

Software development is full of business analysts whose job it is is to gather requirements, analyse them and propose solutions in consultation with technical staff.  It’s a very logical, rational process.  Business analysis is great because good analysts ensure a good coverage of requirements and system needs.  The problem with analysis is that it does what it says it does – pulls things apart, strips the engine to its component pieces to be comprehensive – but focuses less on how these parts are assembled and how people will make sense of them.  Business analysts are a bit like police – just the facts, ma’am.  In the functional specification (if there is one) there may be a flow diagram or two, clarification of fields on a form and so on but the design responsibilities often end up with the developers if only because no one has done the work up front.  In other words, a key part of the project hasn’t been done.  This approach is unthinkable in most product development practices where working hard to assess needs and validate designs is imperative.  The UX approach is to look at who the types of users are, their aims, their preferences and so on and what tasks these users need to do.  Personas and scenarios are modelled visually so that all project stakeholders can understand and comment on them.  This typically moves on to an information architecture/wireframing/visual design phase where key parts of the solution are prepared visually, again by designers who understand the requirements. These deliverables can also be reviewed and signed off by stakeholders before commitment to build so the users know what they’re getting and the developers know what they’re building.  Any scenarios can be reused to test the final deliverable which tops and tails the project quite nicely, ie testing the deliverables with the requirements.  In contrast, the traditional software approach is to test a list of functions individually.  Whilst this should also be done to ensure full coverage, what it fails to do is to evaluate how these functions work together, ie the user experience.

So, business analysts need a sea change in their approach and need to work alongside UX specialists to deliver user centred design.  Conversely, it would be good to see business analysts more consistently involved in the web/e-commerce world to ensure the job is done comprehensively (a lot of design agencies can’t be bothered to test in different web browsers for example – too boring I suppose).  The fact of the matter is that good software and web projects require both the detailed approach of business analysis and the holistic approach of user experience design to ensure that user needs are met both comprehensively and in alignment with real users in real life scenarios.

User Experience Design as Risk Management

Exciting stuff, huh!  There’s no gags, puns, alliteration or other clever stuff in the title of this blog because it’s time to talk risk management which is – as you know – a very boring serious matter.  This blog looks at user experience strategy as a risk mitigation tool for web and software projects.

User experience is often miscast as usability or user interface design – which sound a little bit non-essential and nice-to-have.  Yes, UX encompasses those things but it’s the whole process that is important and sometimes misunderstood.  It’s about getting the deliverable right so I’m not going to talk much about usability or user interfaces here, just plain old projects.  And with projects come risks.  Sometimes risk is all that people understand and if you’re a fan of the psychology of behavioural economics then you’ll know about loss aversion.  In plain English, that means that people are more likely to be motivated to act if they think they will lose something than if they think they will gain something and risk is usually about losing something.  Which is why everyone loves, or rather hates, risk.  That includes project managers and rightly so.  So, let’s not sell the benefits of a user experience and instead sell the risks of not doing it.

Every project pack worth its salt has a list of risks and mitigating actions to ensure project success.  Risks come in many flavours but can include issues such as poor user adoption/loss of confidence, regulatory breaches, costly errors, loss of revenue, loss of reputation and so on.  Those risks can play out both internally and externally at an organisation and everyone wants to get the project right.  So, how do you get it right?  You go to the business or customer, ask them what they want, write it up in to a 72 page document, ask them to review it (which they don’t), call a meeting to talk them through it, chase them to sign it off (which they do – because they want the project done), maybe write a functional spec, hand it to the developers, months go by and, fingers crossed, test against the functional spec and done!

That’s a cynical but not wholly inaccurate take on the so called ‘waterfall’ software development method that has a linear set of steps.  Best of luck to everyone involved.  Unsurprisingly, it often doesn’t deliver to expectations.  People are now starting to turn to ‘agile’ because of this very fact – they have concluded that waterfall doesn’t work.  Agile is an iterative, little and often, show-and-tell approach with lots of questionable terminology (‘sprints’, daily ‘scrums’, ‘war rooms’) to make the new thing sound clever.  Naturally if you show a system bit by bit to users then you can clarify the direction of development which is great to ensure correct delivery but it can be hard to control scope and get the thing finished.  It’s also fun and removes planning and documentation so those that like to avoid such things love agile.  In other words, it manages some risks but raises others.  In some cases agile might work well, especially for an innovative piece of product development but for many projects it just misses out the steps and the clarity required to get things done properly, hence it’s often dubbed ‘fragile’.

So, nothing works.  Ok ok, I’ve been rather unfair about both these methods but the methods aren’t the point – the approach is.  I know waterfall can work well and someone must have seen agile deliver to keep on doing it.  However, the fundamental issues when projects do go wrong are simple – not getting the requirements right, not getting the design right, not getting sign-off right, not doing testing right, not communicating right.  I’d love to see these risks in a project pack – instead of lack of resource and the usual ones PMs feel they ought to put in.

This is where user experience design proper is meant to help: UX is doing waterfall or agile or whatever, right.  A user experience approach entails getting into the shoes of the user, identifying the types of user you have and noting their needs and preferences, observing them using a current system or process, interviewing them, understanding their decision-making processes, etc. It doesn’t have to take that long but proper research needs planning in to the project.  Once you start to gather this information you can clearly map user types (personas) to processes and draw visual diagrams to represent this alongside written scenarios.  These are the sort of documents that users will understand – and will sign off for real.  Requirements done then you can start to design to these requirements through standard techniques such as wireframing (as well as functional specifications).  There might also be a need for information architecture to help organise and label information in the most useful way.  This information should feed into the wireframes and a site/app map if required.  A visual design exercise may then come into play (especially if it’s a web application).  Again, visual designs can be signed off by users before commitment – even if the build has started.  Use workshops to present and validate the design, not to brainstorm and put the onus on the users.  Tweak it and build it and test it, against the functional specification but also against the scenarios and get the users to run through the scenarios – and observe them.  If it’s not obvious for them to use then it’s a problem.  Dig deeper and make changes before final testing commences.  Write a Quick Start Guide to help people understand the capabilities.  Again, ‘test’ it with a few users.

What’s good about this approach is that the users are engaged throughout the process to mitigate against the risk of designing to abstracted requirements.  The users are also involved in the design, sometimes in the information architecture or sometimes in discussing options around wireframes and designs.  There will be few chances for surprise and disappointment.  Also, with a defined set of users you’re doing change management by engaging them and getting them to sign off on tangible deliverables, helping to communicate the change and helping them to own the design.  In other words, the chances of adoption are greatly increased.

So, UX helps you get the system right because website or application building is a design process that needs to go through steps.  When you use words like architecture, design and build then the clue’s probably in the metaphor – it’s not too unlike building a house.  Waterfall and agile are sort of besides the point.  Only the largest corporates are beginning to understand the need for UX for software projects but you’ll see this approach catch on hugely in the next few years so it’s worth catching on before you have to catch up.