When we work in corporate IT most of us don’t create things that people want to use.
We work on things that people in charge of a budget want their organisations to have. This could be because:
- It looks like it might make some money
- It fits within the organisation’s strategy;
- One of the senior people in the organisation think it’s a good idea;
- A competitor or peer has one and your organisation doesn’t want to be left behind;
And the number one reason:
- It looks like it will save the organisation money it’s already spending (saving money being much easier to predict than making money, as well as being less reputationally risky for the budget holder)
I’ve managed a lot of corporate technology projects over the past decade or so, and almost all have been compromised from the start. They’ve started out with the ‘what’, rather than the ‘why’ and the ‘how’, started with a list of features specified (at best), rather than looking at the undertaking as a whole and asking:
- ‘How can we make the job of the people whose job function it is to use this new process / system easier?’
- ‘How can we help them accomplish their work in a dramatically improved way?’
- ‘What is the purpose that we can unite around?’
Projects and systems are usually commissioned by people several hierarchy levels away from the people whose jobs are going to be changed by them, so there’s an inbuilt tension between the organisation’s objectives (some of which are listed at the top of this post) and the objectives of the people doing the work, which are necessarily focused on more operational concerns.
There’s a huge body of work in the field of User Experience (or UX as those in the field refer to it), which focuses on how people use systems based on observation, rather than the more traditional methodology of documenting an processes and features based on an imagined (and not necessarily shared) view, adding elements that will compromise the real users’ experience with every decision.
In common with many people, my UX starting point was the seminal Don’t Make Me Think by Steve Krug, which I came across when my team were looking for ways to challenge a software vendor who claimed their software was intuitive and easy to use, when it was patently neither. Since then I’ve read a lot of books on UX, and the academic discipline that gave birth to it: Human Computer Interaction (HCI). I’ve listed some of the most helpful (a purely personal recommendation) at the bottom of this post.
In creating Speakr I wanted to build something that worked from the user’s perspective, to make it easy for them to use Speakr to make their school lives better. In this case the users are children between six and twelve, and their teachers.
I didn’t start with a specification. Building on the original idea of self-reporting for children in care, I started with the core idea (Speakr should focus on helping children to articulate how they felt at school) and sketches that I iterated quickly as I talked to schoolchildren and their teachers to understand how they interacted, the environment they spent their days in, and the things they wanted a product like Speakr to do.
A strong idea and a plan of sorts helped to persuade two of the UK’s brightest freelancers (Anna Debenham and Laura Kalbag) to join the cause, and we prototyped our ideas to find out what worked and what didn’t. Doing this was comparatively cheap and quick, in stark contrast to the waterfall method used in most big projects where all design decisions are made up front. The fundamental weakness in waterfall is that you cannot possibly anticipate the ways that people will use a system, and you’ll need to make expensive and disruptive changes during the development and testing phases when users get their hands on it. See the majority of public sector IT projects for further details – this one being the latest in a long line.
Being a tiny group made it easy to focus on the product, because the whole focus of the ‘organisation’ was the product. This focus is something that we’ll work hard to keep as Speakr moves forward – when talking about Speakr, people often suggest new features; ‘it would be great if it could do X’, but if X doesn’t pass our design criteria (and unless it’s going to add enough value to persuade me to pay for it), it doesn’t get added. These are the design criteria that have served Speakr well so far:
- Focused – the function of each element (how to use it, what it is for, and how it relates to other elements) is clear;
- Friendly – the visual style, tone of content, and interactions are designed to help the user smile;
- Useful – every element has to earn its keep in relation to the core purpose of the system: to help children articulate how they feel, and to make it easy for teachers to see which children need help and engage with them.
I’ve been working on Speakr for more than two years (when client engagements permit) and throughout this time the most rewarding part of the project has always been talking to children and their teachers about Speakr in their school, and watching them use it.
UPDATE 23rd Jan 2014: We’ve always made our best work when we’ve talked to our users, and when we asked the hundreds of children who use Speakr what they thought of it (through the tool itself of course), it was humbling to have this response:
Making something that people like using involves the hard work to understand how it can fit in with their job to be done (rather than trying to bend them to the will of the organisation), and a lot of time spent thinking your way out of dead ends, but it sure beats the first day of User Acceptance Testing carnage on a big waterfall project.
The Field of User Experience design – a starter for ten
Not all of these are UX-related, but they all focus on understanding why people interact in the way that they do, and that helps.
Designing Interactions – Bill Moggridge
Undercover User Experience – Cennydd Bowles and James Box
The Elements of User Experience – Jesse James Garrett
The Back of the Napkin – Dan Roam
Rework – Jason Fried and David Heinemeier Hansson
Sources of Power – Gary Klein