Trap #8: Divide & conquer

I think by now we’re probably all aware that you’re not supposed to structure your top-level navigation based on your organisations departmental structure. 

And yet - that’s still really common actually, we just swap the department names for their customer-facing equivalent, Fundraising becomes Support Us. That’s why the biggest IA challenge on most projects is deciding what the correct customer-facing term for the Education department section is. Learn? Interact? Dive In? Explore? Go Wild?

But even if we’re not doing that. How do we figure out what our website requirements are?

Usually, we draw together the departments, so that they can take turns reciting their wishlists. This is setting off on the wrong foot for a couple of reasons.

1. Departmental thinking leads to bad UX. If you ask a fundraising department what they’d like from the website, maybe they think every transaction should be interrupted with a colossal donation ask. Maybe that impacts on ticketing revenue, but why should they care? And vice-versa.. The person responsible for the overall UX needs to look at the total revenue to find the best compromise. They can’t be thinking on behalf of one department.
2. Not all departments have the same exposure to end-users, revenue or technology. But by treating requirements gathering as a round-robin departmental exercise all are elevated to the same status in digital terms, regardless of the objectives of the project. This process encourages departments to think of elaborate features that their users might like, without necessarily user testing any of this, or without any reference to a cost-per-user or cost-per-revenue calculation.

Often, the department leading the project, has no real intention of delivering these features. However, they never explicitly reject them, so they crowd development backlogs and schedules until they are finally ‘back-burnered’, causing disappointment and distrust. So to get over the trust issues, the disappointed departments are consulted on the next big project and the cycle starts up again.

Congratulations you played yourself.

Here are some tools:

1. Figure out which department is actually responsible for the project. If it’s a dedicated digital department, answering directly to someone on the board, so much the better.
2. Be clear about the organizational objectives for the organisation and name them in real, user-focused terms.
3. Invite departmental heads, and maybe some of their operational people to contribute to requirements gathering. But not as the representative of their department. They are there as domain experts to help refine the overall requirements. Smart people can work for the objectives of the overall organisation, and will have real insight into how things work, things that are easy to contribute, small changes that could have big impacts for them. That’s what we want.

Trap #10 Building a Monument
Trap #9 100% Digital Coverage
Trap #8 Divide & Conquer
Trap #7 Designing for your CEO’s smartphone
Trap #6 False Prophets
Trap #5 Post-it Fetishism
Trap #4 Building not Buying
Trap #3 Buying not Bodging
Trap #2 Bogus User Stories
Trap #1 Cutting Against the Grain