Home » Uncategorized » The dichotomy of building software and the actual users who use it

The dichotomy of building software and the actual users who use it

@PaulHolland_TWN tweeted a statement by @michaelbolton that said: “One of the things that gets in the way of effective testing is the distance between the testers and the users”

My reply to him was: “Anyone who builds/tests any artifact that users care about, should have more interaction with them”

This has been a sticking point for me for a long time.

Many developers and testers are doing a great job delivering fantastic software for their users. They’re building just what their users want… or are they?

Many developers and testers have little to no interactions with their user communities. How do we really know what we are building is what our customers really want or need?

Is it:
1. Because the developer who is building it said so?
2. Because your manager said so?
3. Because the product management team said so?
4. Because the requirements said so?
5. Because the use case, user story, business workflow said so?
6. Because someone talked to some user somewhere and wrote some stuff down on a piece of paper and then wrote more pieces of paper with details on it and…

There is a significant disconnect in the industry, where the majority of those developing software are kept separate from their users. The old guard still exists – they send in the swat team to gather requirements, come up with use cases, business workflows, best practices in the industry, and write up a whole bunch of documents, hand them off to the R&D team and have them build it, validate it and ship it!

One significant problem… who is our user, how are we building what they really want and how can we validate it properly?

One of the challenges of testing, is trying to portray the persona of a real user of your system. If one has never met one, talked to one, has never seen how they interact with the system, how they modify it to suit them, how it changes the way they do their work (for the good or the bad) and how it interacts with other systems and programs they use, how can we accurately represent them in our testing – especially from a user experience perspective?

In some cases, we have someone who represents the user and conveys user intent and behavior. This reminds me of a game you play as a child, where you sit in a circle and whisper something, then they whisper it to the next child, and so on and so on, then it gets to the last person and it does not resemble the starting point at all. A lot can be lost in translation along the way.

Oftentimes, all we have to go off of is documentation, our own experience, what someone else tells us, our own understanding of the domain we are working in, and workflows that have been preset for our consumption.

Let’s try and change things. Let’s get involved with our users, talk to them, participate in on-site visits, see your product in action! Only then can we really, honestly, say…

“Yes, we are delivering high quality products to our users that they really want and need!”

One thought on “The dichotomy of building software and the actual users who use it

  1. Pingback: Testing Bits – 4/6/14 – 4/12/14 | Testing Curator Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s