Skip to content

Latest commit

 

History

History
43 lines (26 loc) · 3.57 KB

File metadata and controls

43 lines (26 loc) · 3.57 KB

Section 4: Building a Prototype

Lesson 2/3: Getting prototype feedback

You've built a prototype, it works reasonably well, now what?

There are various groups that could be really helpful in giving you feedback on your prototype such as:

  • Customer review. If you are building a commercial product, you definitely want to hear from the target audience.
  • Technical review. Another type of feedback you might want is the technical one. You want to find out early if you are using a reasonable architecture for the software and all other parts that might go with your solution.

Survey

If you can't assemble a group of people in person, you can still gain a lot of insights about your prototype if it can be accessed via the Internet. If you can publish it online and then ask users to do a survey, you can gain insights that way to see how you can improve. Look to ask things such as:

  • Was it easy to use?
  • Would you use this if it was free/ paid?
  • How much would you pay for it?
  • How can it be improved?

Ensure you mix different types of questions where users can rate their experience as well as is able to submit comments.

In-person Customer/User review

So you want to have customers? Of course you do, to ensure your prototype is usable, you want to put it in the hands of people that are its intended target audience. Where do you find such people? If you are targeting a specific domain you need to either have contact in that domain or grow contacts. Maybe there are online forums for a certain domain that you can post on or maybe you know someone that knows someone?

So lets say you've managed to find a group of people willing to test your prototype, what do you want to test for? There are many approaches to use when performing a user test, you could:

  • Guided testing. You can guide a group of people by giving them context what this product is for, what scenarios they are supposed to carry out and a list of instructions that describes step by step how to get there. When you guide your users this much, you can ask them about the experience, did it feel easy to do, how can it be improved etc.
  • Unguided testing. In this type of testing , you give your group of users almost no pre knowledge and possibly only what major scenarios they should perform, and let them figure out how to use your prototype. At this point you need to take notes and observer your users behavior. The pros of this approach is that you will see how good the usability is, does your program have good interaction element, placed in the right places, do a user feel guided through a scenario and so on.

A note here is that you can carry out this type of testing with very low fidelity, i.e you don't need to have an actual working prototype, but it can be enough to have graphical mockups.

Technical review

You most likely want a peer review or even better, someone that's above your current technical level that's able to give you feedback on things like architecture, code quality, sound technical choices like programming language, framework and so on. It might be hard to make changes to programming language and framework, but you want to know early on if you made a major mistake like selecting a system language when you need a programming language that's better at rapid prototyping and web development for example.

It's good to have a set of questions ready like the below:

  • What did you think about the architecture?
  • Was it a sound choice of programming language/framework?
  • What changes would you make if any?

👉 Move on to the next lesson here!