The document discusses using empathy and an inclusive team approach to software development. It advocates developing empathy with real users through field visits where the entire team interacts directly with users to understand their tasks. This helps inform rapid prototyping and development that results in a product meeting user needs. This approach led to the team successfully replacing their mobile product ahead of competitors and growing their business.
3. Adversarial relations…
“Fight your corner…
never let up or they’ll
crush you”
“Stand your ground…”
“Make sure you keep arguing the UX
case… don’t let them browbeat you…”
“Daily struggle… keep on the front foot…”
“They might get it eventually…”
4. What did we want the team to be like?
• All about:
– Avoiding assumed consensus
– Gelling the team from Day One
– Rapidly moving in the right direction
– Establishing empathy with users
• It’s NOT about:
– Specs
– Requirements docs
– Detailed plans
– Detailed designs
– Documentation is risk, not risk management
5. Bad old days
• PM Spoke to ‘the customer’
• This meant the person who signed the cheques
• Resulted in us building a major new feature
• How many users actually used this feature when it was
delivered?
6. Empathy with users…
Engineer – Product Manager – Account Manager – Buyer – Supervisor – User
• Don’t just ‘study’ or ‘understand’ customers
– Need to really EMPATHISE
– Real user input NOT ‘user proxies’ or buyers or personas
– Engineers talk DIRECTLY to the users
– Engineers ALWAYS attend field visits
9. The WHOLE team goes into the field
• Working with the real users on real jobs
10. And we do mean the WHOLE team…
• Left to right:
– Graphic Designer
– Software Dev Lead
– User
– Technical Architect
• …on a freezing morning
in Chatham, England
11. Some context
• What is Confirm?
– Highways asset maintenance management
– Manages over $1bn of infrastructure assets globally
– Over 20 years old
• Existing Confirm Mobile
– Field based extension of Confirm desktop
• What we were doing
– Replacing Confirm Mobile
– Being first to market with a smartphone and tablet offering
– Expanding the customer base
21. Empathy-driven development
• …the team’s workspace lived and breathed the
customer… photos of real users (not personas), their
artefacts… their desks…
26. The secret sauce
• We empathise with users
• And we trust each other
• And we make decisions together
• And all this allows us to be truly lean (as in eliminating
waste, for example, personas and throwaway
prototypes)
• And that’s it, really
27. Final result…
• Standing start to market leader in 9 months
• 18 months ahead of the competition
• Users of competitors’ products requesting demos
• Significant pull-through sales of desktop solution
• Confirm business grew 25%+ in 2013
28. Side benefits…
• Huge PR side benefits
• Customers see the process happening
• Industry perception of activity and progression
– Clients see progress rather than early announcement followed
by radio silence for 18 months
• See responsiveness
• Engenders trust
• Feel valued
• They spread the word
• Happier to take the product earlier
• Discussions about features fade away
29. Inclusivity learning points
• Understand the culture
• Speak the language
• Be subversive; bottom up not top down
• Find the hot buttons
• Don’t try to change development practice
• Evangelise by doing
• Be visible
• Make allies
• Be inclusive
• Share ownership of artefacts
• Explain & accommodate… don’t dictate
• They want to learn
• Have ground rules
30. Developer quote
• “This has really opened my eyes… I can’t believe I’ve
been developing for seven years without doing this…
this is the first time I’ve really understood why I’m
coding something… previously if I hit a problem and
needed guidance, I’d ask the product owner and he’d
tell me how to solve it but I still wouldn’t understand
why it had to be done like that… now I’ve been part of
this I can’t imagine how we ever managed to build
anything useful before…”
31. Take a bow… the team
• John Castle
• Kevin Fitzsimons
• John Gomersall
• David Haynes
• Keith Manning
• Liz McKenzie
• Paul Miller
• Rob Savage
• Vaughn Stanworth
• Adam Taroni
Rule: tech & design staff will come on field visits to see things first hand
Confirm is software used to manage physical infrastructure assets such as roads, bridges, street lights, drainage assets and whole lot more.
Put very simply Confirm stores information on what the assets are, where they are, what condition they are in, what works needs to be done on them and when, who should be doing that work, how much that work costs, can create invoices, has contract management rules built into it.
It is an extremely comprehensive and scalable system with over 140 components to chose from.
It is predominantly sold in the UK and Australia although we have clients further afield such as Philippines, Fiji, New Zealand who use it to manage their road networks and related assets. It is the market leader in the UK which over 100 public and private sector clients gained over the last 20 years.
Confirm Mobile is our existing mobile extension of Confirm for site based working, allowing staff to access and collect information in the field.
Today’s presentation focusses on the process we went through to replace the existing Confirm Mobile application with the goal of being the first to market with the next generation of mobile asset management software.
So here you can see the existing Confirm Mobile user interface and a range of devices which by today’s standards look rather outdated.
Observe the minutiae of the daily tasks
What’s a gully in American?
Rule: tech & design staff will come on field visits to see things first hand
Observe the minutiae of the daily tasks
What’s a gully in American?
Artefacts are revealing
Early visualisation – ideas worked out collaboratively using inputs from field visits – start building straight from this
So this is an example of how the design evolved, not in a document or on a white board, but in the product
First picture was an HTML5 mock up to just help have a conversation
Next we see our first stab. We thought an analogy with email would help, so you have an inbox, drafts (work in progress) and an outbox (stuff being sent back to the server)
We then needed to introduce symbols to differentiate between different types of task
We decided that it was a bit disconcerting for something to move from the inbox to the drafts tab when you started to edit it so we merged it into the Inbox but now with some status indicators to show where you were up to with each task
It took a few iterations with colour and symbol to get something that users found intuitive. So we have the ides of read and unread (with the *)
We introduced alerts on the Outbox if there were problems
Eventually we found that the Email analogy wasn’t working so we switched to “Transfers” which might not work for everyone but was a term our users were comfortable and immediately familiar with
Most recently we started incorporating urgency into the icons. Users didn’t really need a symbol for unread, although we still use bold styling
It might seem like it was wasteful to make all these changes, but if we’d tried to do the design up front we would have probably had just as many iterations, it’s just we would have wasted a whole load of time NOT getting the software into the hands of users
Waterfall is a symptom of a lack of trust…
“I don’t trust you to revisit my requirements in the future, so I will write down everything that I might possibly need in a specification and I won’t pay you until you deliver everything”.
You have to earn that trust with customers and users and the easiest way to do that is to give them something, listen to their feedback and then give them something better.
But trust has to happen internally too. The Product Manager has to trust the Engineering team (including UX) to meet his stated goals in the best way that they see fit. A list of Features on a roadmap shows a lack of trust
A UX team designing the entire screen flow for an application before the first line of code is written also shows a lack of trust – “I don’t trust that you are willing to change things when we get feedback”
A Salesman needs to trust the whole team so that when he says to the customer “don’t ask me for features, trust me, this will solve your business problem” that it really will!
So what happens when you build trust…
Waterfall is a symptom of a lack of trust…
“I don’t trust you to revisit my requirements in the future, so I will write down everything that I might possibly need in a specification and I won’t pay you until you deliver everything”.
You have to earn that trust with customers and users and the easiest way to do that is to give them something, listen to their feedback and then give them something better.
But trust has to happen internally too. The Product Manager has to trust the Engineering team (including UX) to meet his stated goals in the best way that they see fit. A list of Features on a roadmap shows a lack of trust
A UX team designing the entire screen flow for an application before the first line of code is written also shows a lack of trust – “I don’t trust that you are willing to change things when we get feedback”
A Salesman needs to trust the whole team so that when he says to the customer “don’t ask me for features, trust me, this will solve your business problem” that it really will!
So what happens when you build trust…