How to Make a Great Software - Meet the End Users

Did You ever wonder why some software is so great to use and some other just makes you frustrated? How some software is so popular and some other, no matter how great features it offers, isn't used at all?

Is there some magic formula which helps to build a great software, which users will love to use? Actually, answer is YES. And the formula is quite simple - IT'S ONLY IMPORTANT WHAT END USER WANTS!

This sounds simple but it's the most common mistake developers make. Developers usually builds applications based on what they like or dislike: "I like shortcuts, I like drag&drop , I like blue colors, I like, I, I, I...". In software development, what developers likes has no importance, it's only relevant what End Users likes. So, let get out from Your own shoes and meet the End Users.

To make great software You need to know how End Users see, understand and think.

Before start any work on software, define Your target audience first. Of course, every man is a different, but there are always some common characteristics which can be used to group users in a target audience and define a standard End User profile.

Don't forget that it's more easy to work for narrow target audience, because trying to make everyone happy isn't possible. It's always better to make one of two happy than make a compromise and leave all unhappy. For example, if You are a musician and making a song for rock fans and for country music fans, you will make something which will sound to much country for rock fans and to rocky for country music fans. Of course, some compromises are possible. Great example is a famous animated movie Shrek, which is made for all, from 7-77 years all, for both sexes, all social levels. But, don't forget that people who did this movie aren't from this planet... in software development is rare to make something for so wide target audience.

When You trying to define standard End User profile search for some dominant characteristics, for example:

  • age group,
  • sex,
  • profession,
  • computer skill level,
  • habbits, etc.

Age Group

Application for small children from 7-10 should have a BIG letters. These kids usually aren't good readers, so make reading as easy as possible. Similar is if You making something for 40 years old or older people. They doesn't see so sharp, so avoid small interface elements and small letters.


If You are making application for men don't make graphics which looks too girlish. Men usually likes clear and strong lines, simple interface without to many details. Women are usually more sensitive on visual appearance of products, they like elegant and curved lines. Try to see some cosmetics products for inspiration.


For example, Financial Experts love numbers and tables, Visual Artists love interesting images, System Administrators love command line interface... any profession has it's own favorite ways dealing with tasks.
If You are building a software for a specific tasks in some specific profession, find out how these tasks are done, which workflow is used, which terminology is used. In this way End Users will found Your product intuitive and easy to use.

Computer Skill Level

It's common that End Users has some novice computer skills. But, in some cases, You may have End Users with beginner computers skills. For example, if You are develop a software for kids, people from village or old people, they usually have less computer experience. People with beginner computer skills need wizards, simple operations, simple structures, they have low motoric skills with input devices, they doesn't know interface conventions, so stick to some basic interface elements.
Android usually has a touchscreen as input device, which is a very intuitive and easy to use for computer beginners.

Usability Testing

Your conclusions based on target audience are here to help You to make a good start, but still You need to check if You are going in good direction during development.

For example, Blizzard did very smart thing with Starcraft. They released early beta version and listen users feedback. This helped them to detect bugs, but also to find what End Users love, and what they dislike about this product. This early feedback from community was crucial for product transformation from game which gamers dislike to one of the most successful game of all times.

If You are using some standard interface conventions, on which target audience get used to from similar applications, then testing isn't so much necessary. But any new concepts must be tested in some way. The simplest way to test is to find someone from target audience who didn't participate in development to test it and say what he likes or dislikes about it. Also check if test user had some difficulties during using Your software.

Of course, if You are in the good mood and have nerves, the best thing You can do is some REAL Usability Testing.

Let me give You some tips how to do Usability Testing on example of Zoom Menu I develop some time ago.

I wanted to test how users will understand interface elements, how will solve some basic tasks. So, first I define what exactly need to be tested. One of tasks was returning to previous navigation level. I decide to test it after User went on second level of navigation with a simple question: "How do You think to go back to a previous level?" . Initial design had a button with an back arrow icon, as a back button.

Always find some objective way to test. For example:

  • percentage of task completed per unit time,
  • ratio of successes to failures,
  • time to complete a task,
  • percentage of number of errors,
  • number of runs of success and of failures,
  • number of times the interface misleads the user,
  • number of times the user expresses frustration or satisfaction, etc.

Than I build some working prototype in Adobe Flash. This prototype has implement just a basic graphic design and basic features which were object of testing.

Than I found some "victims" for testing. These test subjects has to be a people who didn't participate in project development because it will affect on testing results. If You have some nice project budget, You can afford to pay test subjects... or You can asks Your friends and families to help You. Test subjects must be from target audience.
Just keep in mind that You can use these victims on a single project only once, because test subject must be without previous knowledge about project or it may affect test results.
If You wonder how many "victims" You need for testing... some studies recommends at least 10 test subjects because it brings average percent of problems found of 95%.

Don't test in groups, because social interactions can affect test results. So, I did testing in isolated environment, with a single test subject per testing, just to be sure that testing will be objective and clean.

Before testing You need to talk with test subject. Explain him that You don't testing him, You test a software. He cannot be a stupid or wrong, only implemented design can be wrong. On this way You relax test subject so he will acting more natural.

During testing my "special question" showed that I have a problem. Test subjects said that they expect to go back to a previous level by clicking dimmed previous level group. No one said that they expect to go back by clicking on a button with back arrow.

Of course, I added support for going to previous level by click on dimmed previous level group.

So, I analyse all testing results, make some conclusions and implement solutions which I thought it will fix issues. After it I repeat testing. Testing results usually shows some issue You never think You'll have.

People was amazed with final results and enjoy in Zoom Menu interface. But, basically I didn't do anything special, just listen and analyse what End Users have to say...

Some developers avoid to test their software or to release some early version for collecting End Users feedback. We are all humans and dislike to be criticized. But all this pay off at the end, when we got a software which End Users love and recommend. So, don't hesitate and meet the End Users.