5 lessons from an Information Architecture career
Today I delivered the opening keynote address at the Polish IA Summit in Warsaw, entitled “Come as you are”. It is the story of how I’ve come to spend 13 years building digital products, and how I’ve observed and been part of the changes and development in the UX and IA disciplines over that time. It finishes with what I consider to be the five key lessons about computers and people from my career as an IA practitioner. Here they are...
1. Pragmatic UX ships software
Everybody admires the design ethics and refusal to compromise from Apple. But the chances are that you don’t work for Apple, or for a company that has a design ethic anything like Apple’s. Pinning your hopes on the aspiration for your company’s design process to change in that direction will frequently leave you bruised and disappointed.
Over the years I’ve learned that pragmatic UX that gets software shipped is more valuable than perfecting your pre-build documentation.
This lesson is very much tied up with the ideas of progressive iterations, and improving things from the base of a ‘minimum viable product’. I’ve sat in rooms trying to descope a feature set to get it pared back to an achievable release #1, and been warned about taking so much away that it ceases to be a compelling product.
There is nothing less compelling than shipping nothing at all.
Websites can be changed post launch - that is the beauty of the web. If you’ve got the fundamental data model underneath a system right, then getting the design from 85% brilliant to 95% brilliant can be done post-launch.
And even if you’ve been meticulous in your research, the chances are that you’ll need to re-prioritise your post launch optimisation based on genuine customer feedback. And when you do make post-launch changes, make sure that you are adding the 10% polish that matters to the users, not to the business.
2. Have empathy with the rest of your business.
I’ve heard it described as an arrogant assumption to think that as a designer you can have “empathy” with the audience, but our role is so often to be the eyes, ears and voices of the end user during projects. We carefully research what motivates them, and develop strategies to present information for them in a way that they understand, at just the moment when they want to use it. We strive to delight them with designs.
And yet...inside our own businesses we often consider the marketing department the devil, and the commercial department callous and greedy, people who don’t care about the experience of the user.
Of course they care about the experience of the user, but they have a lot harder targets to reach than we do. Measuring “emotional satisfaction” with an interface is one thing, measuring cold hard cash is the difference that pays our wages.
A successful IA will do more to empathise with colleagues from other areas of the business. Read some books about business strategy or marketing or advertising. Get to know your colleagues in different disciplines - I know this is scary because we veer towards shyness and introspection - but above all, speak a language they understand. You wouldn’t label your primary navigation with terms that your audience found unfamiliar, so why give a presentation that talks about “user journeys” when your financial director is aching to hear the words “improved conversion rate” - which is what your improved user journey is ultimately designed to deliver.
Empathy doesn’t mean always agreeing. It doesn’t mean giving in and compromising in every single detail. But it does mean understanding that the marketing team are not there to destroy your precious UX and perfect IA, they are there to do marketing, just as you are there to do IA. Every single product success case study I ever hear seems to have at the heart a well-balanced cross-disciplinary team working towards a common goal. Don’t let your failure to empathise with other bits of the business be the reason a product fails.
3. Earn the trust of your developers
Software developers are the people who make your user experience real. Sure, marketing determines a brand, and product management sets the direction of travel, but ultimately it is software developers who enable what happens when somebody clicks a link in your website or app.
Earn their trust.
If they trust you, then when you are prioritising the features that are going to make the UX better for end users, they’ll listen more than if you just appear to be saying the equivalent of “I want it blue”.
Take developers to user-testing sessions or debriefs, share links with the team about UX and IA best practice. Bring them into collaborative sketching and whiteboard sessions.
Earning that trust might mean getting a bit more technical yourself. Read about software development processes, take time to learn about the systems architecture of your business, and what the strengths and weaknesses are according the software developers who are most involved in it. I’m not saying you have to learn enterprise class Java, or immerse yourself in Slashdot or Stack Overflow, but be aware of the technical landscape within which you are working.
Most importantly, you know that at the last gasp of any product launch, there are always a couple of niggly problems caused by things you didn’t quite specify right, or because of some misinterpreted technical details. Earn your developers’ trust, and they’ll be more inclined to get you out of a hole quickly if you ever need it...
4. Lead by example
You spend all your days worrying that what you deliver as a business to end users meets their needs, echoes their language and understanding of the content they are trying to access and the tasks they are trying to achieve, and leaves them feeling satisfied and having had a good user experience.
So what do you do to make sure that you are doing the same thing for your colleagues? Do you ever get feedback from them on the usefulness of your deliverables? Do they come in the right format for them, with the right level of annotation? Are you doing certain types of documentation out of habit that nobody uses - if so, stop. You are wasting your energy, and the time that could be devoted to doing things that actually help your projects along.
And do you always test your own ideas thoroughly, or do you hold on to them like precious things? We’ve all been on projects were the feature set has bloated because the CEO or the product owner or another member of the team have insisted something is “must have” because they came up with the feature, not because user research says it is a “must have”. Lead by example, and be willing to give up your pet ideas if research doesn’t support their inclusion.
5. Always experiment
If you are creating digital products, you should always be using digital products. I was in a session run by Marty Cagan recently, and he said that at Netscape they used to be proud of “eating their own dog food”. Now, he says, that sounds like a ridiculous thing to be proud of - I mean, everybody eats their own dog food and uses their own tools don't they?
Well, I don’t think that just eating your own dog food is good enough for an IA. I think you need to eat a lot of flavours of dog food if you are working on the recipes for new ones.
Or to put it another way, if your job is to design search interfaces, use lots of search interfaces. If it is to make a CMS, then try as many publishing platforms as you can. They’ll give you feature ideas, help you understand emerging interaction conventions, and you’ll no doubt come across some frustrating user experiences to avoid.
And don’t be afraid to try new tools and new techniques.
Within the IA and UX toolkit we’ve got a wide range of ways of carrying out research and making deliverables. We are also good at co-opting tools and techniques out of related fields, like service design or content strategy. Don’t worry about being faddish. Find out what works for your creative process, and then find a way of delivering that which works for your business.