Why Experience Designers should be better Information Architects
A robust and flexible IA is the structural integrity of your experience design. Get it wrong and the whole thing could come crumbling down when it should evolve.
Get it right and you are the hero.
As experience designers we combine strategic thinking, research techniques and design techniques. By bringing these three things together we can move at pace through most problems and deliver something of value at the end.
But what about delivering something viable?
I believe that a decent understanding of the component parts of the experience you are designing at a data level is key to designing something which is deliverable.
We work in multidisciplinary teams with non technical colleagues and technical and non technical clients, which is great — the more perspectives on a problem the better.
But that means it is often someone’s job to take the roadmaps, blueprints, prototypes that communicate the multi channel experiences that we design and translate them into technical requirements in order to build something which not only works but can scale and flex when new and unforeseen features, product lines or service dimensions are required.
This is a stinker of a job, and one which is increasingly complicated as user journeys become deeply personalised, across channels and devices and touchpoints.
It can be unfathomable to non technical experience designers.
Throw in the usual mix of client legacy systems, and poor data architectures and you’ve got a real headscratcher.
You need an information architect.
But as experience/service designers we ARE information architects.
When you talk to users about an issue, how they think about a topic, their attitudes and behaviours, and analyse them … you are building an information architecture.
You are developing a map of relationships between information, actors and actions, as organised in the user’s mind.
Then the experiences we design are seeking to work within that understanding.
Now let’s go deeper. The less sexy stuff…
Defining Information Architecture
Let’s go back to the beginning, Louis Rosenfeld and Peter Morville defined Information Architecture in multiple as
- The structural design of shared information environment
- The combination of organisation, labeling, search and navigation systems within websites and intranets
- The art and science of shaping information, products and experiences to support usability and findability
- An emerging discipline and community of practice focused on bringing principles of design and architecture to the digital landscape.
If you want a technical founding in this stuff then Rosenfield and Morville’s two books are a great place to start.
If you want the human perspective, and how to cope with complex information then I recommend ‘How to make sense of any mess’ by Aby Covert.
To me information architecture is about more than what a user sees on a screen and how they navigate a digital space. To me it is about how you structure the information that sits behind the experience in a way that can be used across services, across devices and across features.
It means breaking down a mass of information requirements and putting it into building blocks, then putting those blocks back together in lots of different ways to deliver a coherent experience.
The trick is to break it down far enough so that the information becomes digestible and usable in lots of different ways, while not breaking it down too far so you are staring at information soup again.
All this happens at the intersection of content, context and people, and is founded on user research.
So once you have your experience plotted out, chunk it down.
Audit the information you are presenting, the information required from a user, the actions that need to be completed.
- What are the component parts?
- What can be grouped?
- Are you looking at product sets and user accounts?
- Are you looking at people, events and calendars?
Now think about all the properties that each of your component parts must have.
What are the variables that affect these component parts, are there other similar things that can be grouped? Can one thing be in multiple groups?What are the outliers?
Think behind the surface character of content. Think about how you need to structure the experience.
You want to provide personalised events to a user? How will you know which events users will want to hear about?
To piece it back together you will need to get to grips with how things like taxonomies and metadata work because understanding the mechanics of complex personalised experiences makes designing them less of an act of fiction.
- Taxonomies/Categories (how do you group things together in a way that mirrors your users understanding of the world, are the relationships hierarchical?)
- Tagging (how do you flag certain content and components in order to make them useful?)
- Labelling (what do you call things so that they mean the right to your users?)
- Search/Vocabularies (how do you structure your content so it delivers on human search queries?)
- Security requirements (are there permissions of access to consider when serving up different content?)
- Information governance requirements (do we need to track users actions and keep a record of their agreements and permissions?)
- Marketing intelligence data (what information does the organisation need to collect to continually improve the product or service, and what would it benefit from knowing in order to attract more users?)
- Metadata (how do all these properties come together to form sub data sets for your content and features?)
Getting this stuff right is the structural integrity of your experience.
It means getting your hands dirty
It’s not an easy job, it can be incredibly complicated and will be painful at times but stick with it and get better at it.
If you can master some structured architecture thinking techniques in experience design then it can open up a world of understanding which will lead to better, more relevant and scalable content for users and functionality across channels and devices that your client will love (plus the people who have to build it will thank you).