Have you ever stuck your head under the bonnet of a car and gone “f*ck me that looks complicated, maybe not” and promptly closed it?
Or are you in the camp of “ooh, I wonder how that works?”
I think we can all guess I’m in the latter of the group. I LOVE knowing how things work. It’s actually the best bit of what I get to do.
So you’re probably wondering why I’m crushing hard on mashing up information architecture (IA) and service design (SD). Well, fear not, you’re about to find out.
Not all who wander are lost
But you can bet your a*s if you don’t have a map you’re guaranteed to get lost.
Which is why it leaves me really confused that most big transformation projects I’ve worked on hasn’t started by mapping out what they’ve got. Yes, OK in a couple of cases I’ve been the one who’s made it a priority to map things.
You wouldn’t buy a house (well you can’t in the UK if you want a mortgage) without getting a survey of the property. The survey gives you clarity of what you’re buying, if it’s about to fall down or bits are about to fall off.
You wouldn’t want to buy a dud after all.
So why aren’t we pushing more to survey the lay of the land in product spaces before we start f*cking with them?
Domain modelling
In the past I’ve made it a practice to informally map the structure (or mess) of what I’m looking at. Personally, I quite enjoy lifting up rocks to see what’s under them. Sometimes you can find some really nice gems.
It also puts me in a position of authority knowing what’s where, what it’s doing and who’s using it.
A domain model can be used to model a domain of knowledge around a subject or concept, or it can be used to map a web domain.
The thing I’ve realised recently is that it just maps roughly one thing. Which is good, but it also has its limitations.
Which is where service design comes in.
Blueprint as a bedrock
I’ve recently started working on something that I proposed we start by doing an as-is service design blueprint. I can’t go into details about the client, or the specific problem I’m hoping to help them solve, but I can say they want to make some significant changes and understand some buying pattern problems.
Initially I thought to myself “this is a service design piece”, but then a conversation at the weekend made me reconsider.
A service design blueprint can map everything that goes on behind the screens that the end user sees. Which, let’s be honest, is the tip of an iceberg.
And if you simply map the user journey, or the platforms they sit on, you’re not getting the full picture. That comes when you find yourself asking people “why on earth are you doing it that way?”
To buy a product or use a service on a website there is a team of people behind all that getting stuff onto the website and then into your hands.
There is technology, there are processes, there’s agreements and decisions, there’s money being accounted for, there’s problems with products, there are people who listen to complaints. There’s a LOT.
Which is the beauty of the service design blueprint, it captures all of that.
What’s this got to do with IA tho?
The clue is in the architecture bit of it.
A blueprint shows the architecture of the product including the people, systems and processes.
Used correctly (which obvs it probably won’t be, but I digress), it can be used to identify weak spots, identify where you could make improvements to reduce costs, work out if it really *is* the right problem to solve, reduce risk when you start replatforming or re-engineering something and also to identify when and where to do research with your customers.
I’ve now gone from “oh, that’s just service design” to “that’s a genius information architecture baller move”.
What tools from other disciplines could you use to make your practice better?
