User Experience Explained Part 1

In my current position I have the tremendous opportunity to learn about User Testing and all the facets that go along with it. User testing is not something new, especially to software development. I was actually surprised to find out that it dates back even farther.  The company I work for is a small publishing company and uses user testing to develop better books. I as the developer use user testing to test sites that we are working on. As a developer it is easy to build a product and say this is the best way it can be, or this new feature will catapult us past the competition. But after a round of user testing it can become obvious that the new feature may never even be used as the end user may not know what it does or even what it is for. This is HUGE! If you don’t understand how huge this really is, think about this. What if you could design your site or app knowing that it will have each of the features the user wants and uses?

So in this set of posts I will try to demystify User Testing and the User Experience. To me user testing is the next level of agile development and test driven development. I have read a lot about test driven development but the one set of tests that seem to be missing. In test driven development you create tests to make sure the code is doing what it is supposed to. Why not have tests to make sure the features are reacting the way a user would expect them to?

User testing can be as simple as a paper prototype before you write any code at all. What does the site/app look like? Where should that button be placed? Does the button open a popup or take you to another page? Answer these questions before you start coding anything. Construction companies will not start working on a house until they have detailed blueprints. Even most software development practices state you should have a good plan before writing a single line of code. In the construction company the new home owner sits down with the architect and plan out every detail of the new house. Why not find out what your potential user wants in an app? A paper prototype can tell you some amazing things about how the user actually interacts with your application. So you may say, I just survey my users and they tell me what they want. Well that is great and a lot of companies send out surveys. The truth is if a person fills out a survey, and then you do user testing on that same individual there will be stark differences in what the user said they do and what they actually do. Only one will be the truth.

Paper prototyping can be as simple as a blank piece of paper and a pencil or can be as complicated as copies of a competitors site. The wealth of information you can learn from this simple process is invaluable. You need to be careful when actually performing the test and I recommend working with a consultant if you don’t know much about User Testing. You can also learn a lot about User Testing in blogs and other UX sites. I will try to cover some simple testing in the next few posts, but I am not claiming to be an expert.

Making user testing can be simply added to a sprint or scrum at any point in the development process. Most testing can take less than a week to set up and most of the testing can be done in an afternoon. Similar to unit tests you can run a user test at any point in the development process. One additional caution you really only need to test a few times. More than three or four user tests and you will be wasting your time. You will not gain more information the more you user test. Similar to running and rerunning unit tests when all the lights are green you can not make them greener by running the unit tests multiple times without reason.

So this is an introduction to User Testing and how easy it can be to add it to your already agile development process. Please feel free to comment if you want more information about User Testing.