Why users are constantly disappointed by your software
In all the year’s I’ve been developing enterprise software I’ve experienced several projects that have met all the ‘requirements’ but had users disagree with the experience.
I’ve seen this at the extreme end where developers are literally high fiving each other about how great the software is. (Here I mean the term literally in the literal sense, as in “He literally broke his back building that house” implying a person actually damaged vertebrae during construction, and not in the “it was literally raining cats and dogs” manner the word literally is often abused. Although at one point it did literally rain frogs)
The problem, as your marriage therapist would tell you, is likely one of communication. Take the analogy of a builder, you want to build someone a house so you ask them a whole stack of questions of what they want from their house, after some discussion you finish with this list.
- 3 Bedrooms
- 2 Bathrooms
- Garage
- Kitchen
You have a picture of how it should look at function in your mind, and there even some parts that aren’t that clear. but you’d be able to articulate it if you could see it first.
The builder goes away, builds your house and ends up delivering this masterpiece.
It indeed has the 3 bedrooms, 2 bathrooms and kitchen as well as being super functional. The builder has thought about all the options, “but what if they want to approach the house from the right and the left”. The client is disgusted and it’s way too late to make changes without being costly.
Fortunately, builders discovered this a long time ago and possibly never made this mistake the first time. They communicate in a way that is easy to understand and far less open to interpretation than an excel list. They prototype. A prototype is a representation of something that is yet to be built in order to get feedback. It’s a representation…
In enterprise software this is often completely ignored. I see this happen especially in the CRM space or where software is expected to perform a certain way. We collect requirements from business users, translate them to stories, hand them to a development team in another country, hand them to a change manager to create training material, then after some time call the users back to show them what we’d built. It’s a game of telephone and it’s no wonder we get it so wrong. Literally dozens of people will handle this requirement that is completely open to interpretation.
Prototype cheap, prototype boring
Prototype cheaply, do it on paper, take a few photos and send it around. Record a video narrating each step and send the video over a whatsapp to your client (obligatory note to ensure you keep in conduct with client data protection policy). Prototype the boring stuff… especially the boring stuff. The items that you think you don’t need any feedback on. I guarantee the client will find gaps and it’s best to call this out right now than delay.
This way every developer will know exactly what they need to build, and the client will know exactly what they’re getting.
