Mitigate and move on...

Some of you SIG-IA subscribers might be familiar with this, but recently I've been trying to resolve a rather sticky issue with an ecom site: a seemingly critical piece of the ecom journey was taken away from the UX - descoped - during the development cycle.

Solving this challenge brought to light several issues that just keep coming up in discussion at the moment within the UX community:

1 - Deliverables. Over on IXDA there's a thread about a pattern library that covers the same ground. What should come out of IA/UX and who is it for. Part of this situation with the cart arose because IA specs defined a desirable user experience, but the detail of how this should be implemented was either unresolved or lost in a sea of other specification. When it came to the dev sprints (completed by a 3rd party supplier) pdf page designs were used as the 'specification' and reinterpreted and from the stories that emerged it became clear that the feasibility of some core functionality was very low.
IAs make nothing - we research, conceive communicate. If our deliverables are not effective, then we aren't fulfilling our role. It's more than just picking a software package, throwing it all in and hitting 'generate'. Our deliverables should meet the same high standards of being 'user-or-usage-oriented' as our solutions themselves.

2 - Process. Which brings us to the Agile issue. Dev work in sprints. The site owners have projects and programs and goals. Design and IA is done at a site section level (home page, checkout etc). By the time a sprint can be undertaken, there are already many dependencies in the designs of each feature. Retrofitting user stories to completed designs, which get built on assumptions about tech feasibility, because that gets done after the user stories. It's messy. What ought to happen (in an ideal world without clients, budgets and time-zones) is a high-level IA/UX is worked out and assessed for feasibility by all involved. Then design and dev can work in sprints on features, slowly filling in the big picture. The challenge for the IA/UX here is keeping a hold on the current state of the big picture so that coherence, user flows and consitency can be maintained - any hints!?

3 - The art of mitigation. As an IA/UX, I don't actually build anything. As such, I can't control many of the factors that effect the outcome. My job is to mitigate against and for those factors, and the value of that role has been made very clear in this circumstance. While the debate continues to rage every so often about 'who needs UX anyway' (no doubt fuelled by the massive increase in demand and the dubious skills of many presenting themselves for roles) this situation desperately needed UX. Dev couldn't have solved it. Dev could only sticky-plaster over the individual effects of the descope as they became apparent. Design couldn't have fixed it; they needed to resolve the visual display issues that arose, but that would have resolved system issues on which those displays were dependent (such as the persistence of cookies).

Autocratic or Anarchic ecosystem

We couldn't change the way it was getting built. We couldn't change the available interface elements. But we could mitigate the effects of those for the user through careful use of visual concepts (such as placement, prominence, change in state) and language to manage the expectations of the user so that they were met by the experience on offer. I get nervous when I see IA/UX specs that say 'things should always be like this'. This kind of 'benign dictator' approach is at best over optimistic and at worst damaging to the user's experience.

Apparently, a guy called Eamon Hennessy, who was an anarchist of sorts, once said of rules:

"The good people don't need 'em and the bad people don't pay attention to them, so what use are they anyway?"

He kind of has a point. If all we do as IAs is set out hard and fast, unbending rules for others to follow, then we're in danger of becoming more of an obstacle to good a UX than a creator of one. If we take care to understand the issues of the products we're specifying, in the same way a traditional architect understands steel, plumbing, soil erosion, and respects and seeks the opinions of the experts in these issues, then we can provide guidance to the people that actually do the designing, the development, the marketing, the owning of the products, and advice when things go wrong.

Over and Out.