User Testing Made Easy

In this article I share a recent experience of a user testing session that was conducted. I believe that this experience shows how much easier things become when user testing is performed. Not only does it yield data about your html"}]' tabindex='0' role='link'>Minimal Viable Product (html"}]' tabindex='0' role='link'>Minimum Viable Product)?" href=" Viable Product/">html"}]' tabindex='0' role='link'>Minimum Viable Product, it is also important to meet regularly with real users to gather user requirements during the initial stages of the development of your product – before it is offered to the market – for these reasons.
Users can test your invention before it heads to the marketplace. Sometimes multiple rounds of testing is required in order for your <a class=html"}]' tabindex='0' role='link'>target audience to understand your offering. Meeting with a sample of potential users provides an opportunity to collect data on user requirements for future releases of versions of your product." width="600" height="350" srcset="" data-srcset=" 600w, 300w" sizes="(max-width: 600px) 100vw, 600px"/>
Often when I first come across young start-up companies, I immediately notice that the assumptions of the entrepreneurs are determining the user requirements rather than the reality dictated by one’s specific html"}]' tabindex='0' role='link'>target audience. Second, I also notice a reluctance by companies to conduct their own independent user testing before taking their product to the marketplace. For some reason they think that user testing is too complicated or time consuming for them to perform, when it really is not. This second issue is what I would like to talk about in this article, because I cannot stress more the importance of doing independent user testing and gathering user requirements before going to market and I believe that by explaining the simplicity and power that user testing yields when a company conducts their own user testing, this will become more apparent to people.

The Invention

The product which we are discussing (and I can only reveal a bit) is a touch screen machine meant to be placed in large urban hubs. The machine lets you buy digital credits in almost the same way that a vending machine does. Since this is a new product in its field, one that is just entering the marketplace now, there is always the risk that new users will misunderstand the overall purpose and use of this machine. Just imagine what it was like when they were testing the user requirements of the first ATM’s and how strange it must have been for those users to use it when the ATM was first invented. In a way, we were in this instance testing a similarly unfamiliar product, so we wanted to make sure to test it before it entered the marketplace.

During the development period of this invention, we conducted several sessions of html"}]' tabindex='0' role='link'>heuristic evaluation analyses, which enabled us to make improvements to the UEX of each screen, to gather suggestions of how to simplify the screen flow, and address issues about the complexity of the whole transaction process through all stages of the machine’s interface. We also worked extensively with several content editors, aside from the UEX development professionals, who enabled us to sharpen our use of language in the screen labeling, interface design, and the inside explanatory text that accompanied each screen. This feedback helped us make sure that the written content was short and to the point, yet explained enough to not confuse users.

Test Preparations

Two days before conducting the tests we had our last html"}]' tabindex='0' role='link'>usability session where we finalized the scenarios for testing and also reviewed and conducted a few tests ourselves. We gathered a list of UEX issues which needed to be fixed before the user testing began and then prepared a list of typical users who match types in our potential html"}]' tabindex='0' role='link'>target audience. The users we found to perform these series of tests were friends of friends, people who had never heard about the product but were willing to spare an hour of their time to participate in our user testing session.

Identifying The Funnels

We identified two separate funnels in which we need to focus our attention to understand our user feedback. The first moment was the time period right before the user was in front of the machine. Here, we wanted to understand the perceptions of what people saw, what they thought the machine does, and what benefits they will expect to receive by using it. The second funnel was found during the html"}]' tabindex='0' role='link'>user experience – while they were using the machine. While we observed them using the machine, we tried to capture any perceived problems they had in each of the screens, such as problems with the screen flow or in the user’s comprehension of the product, and also html"}]' tabindex='0' role='link'>Minimal Viable Product?" href="">gathered requirements on how to simplify the whole process for our target users.

Running The Tests

In total, the whole process of user testing only took 3 hours. We had 8 participants in the test, which lasted about two hours, then we spent another hour after the test was completed in order to discuss with the users the outputs we collected and continued to gather as much information as we could from everyone that participated. Each participant spent around 10-15 minutes testing each of the scenarios. We then checked our results with that of both the funnels, the funnel before using the machine and the funnel while using it, and then again collected all the user feedback we could.

Initially we asked the user to use the machine without our help or assistance whatsoever. We first watched the user’s behaviour without interrupting their process of interaction with it. Then, we asked the user to repeat their session a second time, this time while asking us questions and letting them explain their thoughts, impressions, and difficulties.

From this approach alone we managed to understand many issues, some were dramatic while others were somewhat minor.

What Happened Next

Following the tests, we then made arrangements for a second round of user testing and for implementing our ideas and improvements before going out to meet our real audience. We also plan to do more user observations in the venues where this machine is going to be located, and hopefully we would like to interview real users that have used our machine in order to improve it and their experience of it. All this feedback will go back into the development cycles, being prepared to release a new version of the software that runs on this machine every week until it works smoothly and every html"}]' tabindex='0' role='link'>user experience is accommodated for.


Conducting user testing is essential. It allows you to understand both the user requirements and also locate on time problems in the user flow and html"}]' tabindex='0' role='link'>user experience. Our conducting user testing was easy and not time consuming, unlike what most people perceive it to be. Implementing sessions of user testing between development cycles helped us gather the most important requirements early and also allow us to directly understand how user problems can occur when using our product.

About David Rashty

David Rashty, an entrepreneur and one of the early web pioneers, has over twenty years’ experience as a CTO and a CEO. David is the funder and CEO of CreativeMinds which focus on WordPress and Magento products.

Post Navigation