Feb 21, 2009
The Information Architect and The Developer
About 10 years ago I was brought into a digital agency, with a burgeoning technology arm, to help them get better at delivering websites. At first, I was sat with the web developers, but over time my audience widened to include both Information Architects and Designers. That’s when the sparks started to fly and I was plunged head first into the world of mutual disrespect between all parties.
Things have moved on (a little) since then but I would like to share some of things I learnt back then, and mix that in with what I still see today. If you have any thoughts in and around this area, I would love to hear them. Be sure to let me know from which vantage point you’re coming from when commenting though… š
10 years ago…
Developers on IAs
Information Architects, formerly known as Experience Architects where regarded as fundamentally lazy by developers. I clearly remember a developer summing up what they thought of IAs:
God damnedĀ time munchers. All they do is talk and draw. The stuff they deliver is simple, incomplete, but above all something my grandmother could knock up on the way to collecting her pension. They take forever to create, and I use the term ‘create’ in the loosest sense, stuff that leaves precious little for us to do theĀ real workĀ and deliver the web site. What a joke!
Then there was the money. IAs were billed out at higher rates than developers. Everyone knew this. This left developers feeling devalued in the eyes of their customers. This only served to fuel their resentment of IAs.
This was not productive.
IAs on Developers
There was an air of arrogance and self-importance that flowed through the IA camp. Developers didn’t get websites. That was the mantra. They built them to order and it is us, the IAs, that were responsible for bringing order from the chaos. We know what the customer wants. A senior IA told me back then:
People, well developers, don’t understand what we do. That’s okay. I don’t expect them to. But I do expect a certain level of professionalism from them. It’s like working with kids. I don’t have time for this.
Fact. The IAs were closer to the customer. Fact. IAs understood the challenges facing customers. Fact. This was NOT communicated downstream. Developers were seen as people lower down the food chain. As a result, IA deliverables were treated with skepticism and often dismissed out of hand.
This was not productive.
Present Day…
This still goes on. But IAs are now common place. I value, depend and actively seek out IA. It’s not optional. However, developers need to understand more about IA and IA need to actively reach out to developers. They have a lot in common.
It’s funny that sometimes when I meet new IAs and/or read about IA, they still feel the need to justify their existence. When you spend an eternity bringing order out of chaos, where the deliverables are simple, and nobody appreciates/values the effort expended in getting there, it’s tough. However, this has been something developers have been dealing with for decades. The complexity required to model software systems that a customer values is a thankless task. For IAs, developers are downstream in the process. They have not participated and/or understand the reasoning behind key information-based decisions, and as a result are the ones that don’t appreciate their work.
Content Strategy
I’m becoming more and more addicted to content strategy. The only way for IAs, developers and designers can move towards having a mutual respect and/or work more effectively together is to bring them closer together. A content strategy does just that. Unfortunately, I see very few customers with a content strategy. Also, most customers bring in the technology solution at the end, when all the key decisions have been made. The challenge is to educate customers and upstream disciplines, such as IA and creative to bring key project stakeholders to the party early. When that happens, customers get better value for money, and less waste spent on re-work.
You Said, “Also, most customers bring in the technology solution at the end, when all the key decisions have been made.”
Are you suggesting we bring in the technology solution at the beginning? middle? Also, shouldn’t a certain amount of strategy and architecture be done before the solution is considered?
Thanks for replying BT. The point I was trying to get across is that the technology decisions should be left until the end, but as you rightly point out, they shouldn’t be used to prematurely influence the strategy.
Ideally, the approach should be a healthy mix of tech, business, ux and content, delivery in small batches, where organisations think big, but start small. Do the blue sky thinking but then ground it in reality.