Why is it hard to think like your software’s user?

This week, I have stumbled upon book named 97 Things Every Programmer Should Know, more precisely, the list of contributions to this book. I’ve read a few of them that had particularly interesting titles for me. I want to add my three cents to the issue touched in Ask “What Would the User Do?” (You Are not the User).

Softwate developer’s perspective on the app

All of the observations in the aforementioned article are valid. However, there are also other obstacles, which contribute to the fact, that programmers usually have a hard time getting into shoes of the users. In the projects I’ve been working on, most of the development time is spent on a locally running instance of app or on the shared development environment. On such enviroments, there is not only fake data (lorem ipsum-like or just pure glibberish), the machines used to run are usually less powerful than production ones. Those facts mean, that I, as a developer, am used to seeing not the real content of application, plus it usually runs slower than the end users app.

Fake data can be a problem when it comes detecting visual glitches in UI. Having fake data won’t allow you to see how the UI behaves on the production – actual descriptions or titles may render improperly (overflowing, etc)., the pagination may run slowly if you have 1 million records in the production database (compared to 1000 on your development machine). Yes, you probably will have a test user for the production environment, but depending on business domain, it may not be feasible to have valid, real-life data for that user, for various reasons.

Other than that, unless the product owner is an actual user of software, you may not know what user really expects. What action is the most important in specified use case? Which features are used in a hurry? On what device? There are more such questions and you have to make some assumptions about the user’s desires in order to implement features. These assumptions can because chances are that you are not the user of the developed software. And if so, no matter how empathetic you are, there are questions you can’t answer correctly.

Conclusion

All that being said, software is still and will be developed. Agile software development principles, which are basically mainsteam nowadays, mitigate the aforementioned issues by reducing the time between users’ feedback and deployments, which deliver software better fitted for the user. But it seems, that the issues won’t be eliminated – you have to get your software out to the world to get feedback, improve and reiterate. Eventually, the product stabilizes, but getting it right the first time – that’s a challenge.

Advertisements

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s