How do you tie your shoelaces?

or, users don’t always know what they know

If you’re reading this, then you can probably tie your own shoelaces, and have been able to for a long time.

Despite all that shoe tying experience, I’d bet that if someone asked you to write a clear set of instructions explaining how to tie a pair of shoelaces you would struggle. Honestly, you would¹. This is because:

1. Some things are much easier to show than to tell
2. When a task becomes second nature it can be difficult to break it down into its constituent parts

So, what does this have to do with developing software?

Good question.

One of our big deliveries in the first half of 2021 was a new app that allows Arnold Clark mechanics to record their work digitally, and then send their findings directly to the customer.

Previously, this was a very time consuming manual process:

1. The mechanic would write their notes on a paper job card
2. This would then be passed to another member of staff to manually enter the mechanics work into the system
3. A third member of staff would then call the customer and tell them over the phone what the mechanic had found

This was bad for at least three fairly obvious reasons: one it’s inefficient, two it’s slow, and three it allows mistakes and miscommunication to creep into the process when the written record is being typed up and relayed to the customer by phone.

Digitising this process from end to end was not a small undertaking, and has taken about a year from start to finish.

Now, being diligent product people of agile mindset, we didn’t just sit down with a long list of requirements twelve months ago, put them in priority order, and then start writing code until the whole system was delivered. Of course we didn’t.

Instead, we spoke to our potential users, learnt how the existing process worked, identified its essential components, and thought about how we could turn those into nice user friendly software. We produced a variety of possible designs, and showed these to people at all levels of the business to get their feedback. We built an MVP, piloted it at a small number of branches, and over a month or so identified the big problems, ironed them out, and improved the app to everybody’s satisfaction.

We’d covered every angle, listened to our users, run a pilot and improved the product beyond all recognition. We were ready to roll out across the group, and being a great user focussed team, we even added a small feature that allowed mechanics to send us feedback directly.

Feedback that we expected would 99% positive and 1% minor complaints.

Then we read it, and there were a lot of disgruntled users.

The tyre problem

A car has four tyres, you probably know this.

What you probably don’t know, is that to a mechanic these four tyres are respectively: the nearside front (NSF), the offside front (OSF), the nearside rear (NSR) and the offside rear (OSR).

From above it looks like this:

This is a car from above, sort of

Our mechanics measure the tread depth of every tyre, on every car that comes in to an Arnold Clark service centre. They do it so often it’s second nature, like tying shoelaces.

We knew they took these measurements, because we’d spent a lot of time speaking to users, and from the earliest designs the new app always had section for entering the tread depth for each tyre on a car.

Because we’re all English speakers who read from left to right, then top to bottom, the app asked mechanics to enter the tread depths in the following order:

This is still a car from above, if you use a bit of imagination

Makes sense, right?

Wrong.

A mechanic normally takes the tread depths of a car by walking round it in a circle, like this:

No, the drawings aren’t getting any better, but don’t worry this is the last one

Our app was asking them to enter the tread depths in the ‘wrong’ order. It doesn’t sound like that big a deal, but it was really annoying our users and it’s not hard to understand why.

Most of them had been doing this for years before we introduced the app, and it obviously makes sense to walk round the car in a circle while measuring the tyres. We were making them do it an awkward ‘Z’ shape, that went against both common sense and their established process.

So we fixed it, case closed.

Lessons

Well, sort of.

This problem has been bugging me, because it feels like something we should’ve picked up on, but on reflection I can’t see how we would have.

As best I can tell there are three lessons to learn (or re-learn):

User don’t know everything they know

The mechanics never told us about circling the car because it was too obvious and too ingrained. There’s definitely a need to watch what people do in addition to listening what they tell you, but there will always be something you miss.

MVP users have a different baseline than all subsequent users

We spent a lot of time with the MVP users, and got a lot of really valuable feedback, but they didn’t mention the tyre problem. My best guess on this is that because they saw the app at it’s most basic and buggy, the tyre issue didn’t come anywhere close to the top of their list of issues. Post-trial users rightly have a very different set of expectations, they should be starting with a much better product than trial users, so their perception of problems will be very different.

You can never have too much feedback

Well you probably can, but whatever amount of feedback you think you need, you need more than that.

1. Well I did, but you’re probably a more intelligent and conscientious person than me.