The path to innovation
Traditionally, the role of a Business Analyst is to gather requirements and generate long functional specification documents full of excruciating detail and dry-as-dust exposition. A bad requirements gathering exercise can stifle innovation and places constraints on a solution that leaves no room for creative thinking. Obviously we need to get the detail down, and in a form that is usable by developers, testers, and quality assurance, but why can’t it be compelling? Why can’t it tell a story about how the product is used – not just what it does? Business writing should be electric. It should be as inspiring and engaging as your product is.
If you just write a checklist you’ll get screens full of text fields and checkboxes – a forbidding mélange of functionality that in essence meets every conceivable need but becomes an end-user’s worst nightmare. Since arriving at Xero a couple of weeks ago it seems there’s a real awareness about what customers are in a rush to escape from.
I joined Xero because it shares three ideas that I think are extremely important in software development. None of these are new ideas, but seeing a software company actually put them into practice is a novelty.
1. Trust in design
It amazes me that there are still software companies out there with no designers on staff. Or worse, they under-invest in design by recruiting young design grads who are paid a pittance to colour-in the creations of brilliant but aesthetically challenged engineers. But skinning is not design. I was attracted to Xero because it puts design first. It has a world-class team of experienced designers who can take a set of requirements and use them as a springboard to excellence. But Xero also has world-class engineers. They provide top-class input, concentrating primarily on technical design, so Xero keeps humming. They’ve created a system that performs well, has integrity, and complements the product experience. By relinquishing control of the product experience to a design team, the engineers are helping create something that people not only use, but love.
Blindly following a spec might give you a correct answer, but without design, you won’t get the right answer. Xero wants to get accounting right, and that’s hugely exciting.
2. Some requirements are seen, not heard
Requirements gathering should be an exercise in anthropology. When you ask a person to analyse their own behaviour, they may tell you how they think they should behave, or how they think you’d like them to behave. And if they’ve been using a particular piece of software for a while, they may undergo an escalation of commitment where they think that the way they’ve been forced to do things is the right way, and despite a desire for improvement they cannot conceive of anything better. So, the solutions they propose end up looking like what they’ve already got.
By sitting down with people in their place of work or in their home and watching them, you might see things that they themselves don’t notice. Maybe they move data from one spreadsheet program to another or manually add spaces to a text file for import or other crazy behaviour. Or maybe you’ll notice that the sort of programs they have on their desktop, the news they read, the things they value – anything you observe can give colour to the final design.
Xero has looked at accounting anew, and has found that people have been doing crazy things for years because that’s what the incumbent software made them do. Finding that craziness and curing it with sanity is fun!
3. Story rules
In software engineering, processes are described using use cases and scenarios, and in Agile development with user stories. But when the story begins and ends on the borders of a software system, it lacks humanity. Tools like personas and context scenarios, as championed by companies like Cooper, help us design software around implicit user needs and create real stories that inspire designers, rather than constrain them.
Stories tell us the how and the why of good software. And you know you’ve got it right when the stories that you’re telling are elegant, inspiring and exciting. If your stories are plodding, repetitive, random, and nonsensical, you know it’s time to go back to the drawing board.
So are the stories around your software engaging or nightmarish? What crazy behaviour have you seen reinforced by bad software? Where does design sit in your development process, and who does it?