It does not appear that you are actually testing your prototype at all. You're showing individuals (perhaps not even adequately vetted target users) a paper mockup and asking them "what do 'ya think?"
User Testing is a structured observation of the user actually doing. It is a detailed process that involves:
- recruitment of participants that represent your user base
- developing test protocols
- defining structures tasks for user to complete
- defining scenarios in which those tasks exist
- observing the user perform those tasks
- collecting qualitative and quantitative data based on those observations
- perform post-test comments & questionnaire
User Testing is not just walking up to someone you think might be a "user" and asking them open ended questions. Data received from showing a person a mockup and asking "Is the 'Products' block located in a convenient place?" is nearly useless. It lacks context. It lacks purpose. It lacks any connection to a real work flow.
I don't care if someone thinks the 'Products' block is located in a convenient place. What I care about is if the UI allows the user to complete their work flow in the most straight forward way possible. You have to have them execute that work flow in order to figure that out! A properly conducted user test allows you to observe if the block is in the right place or not.
Post Test Questionnaires are not free form questions designed to ask the user "what would you do?" It is your job to figure out what to do, not the users.
You can again find many examples of user testing questionaries on your favorite search engine. They come in many forms, but here is a somewhat generic one:
Things to notice:
- It doesn't ask open ended questions
- Responses are on a 3-, 5- or 7-point scale (or other type of scale)
- It doesn't ask for advice
- Questions are functional, asking how well the UI did in helping the user reach their goal
You can certainly add some open ended questions to your questionnaire, such as "what are the 3 things you liked the most?" or "what 3 things did you like the least?", but they (1) are at the end and (2) don't represent the bulk of your data gathering.
But it's all on paper! Doesn't matter. You can find a great deal of information on how to perform a paper prototype user test. Just one of those links, "Paper Prototyping As A Usability Testing Technique" at Usability Geek, breaks it down very well. Among the information is who you'll need:
Paper prototypes can be used to conduct usability testing of any type of user interface – be it a website, mobile application or software. To be able to do so, you need the following people:
Real Users: As stated by Jakob Nielsen, 5 users should be able to identify about 85% of all usability problems. These users will interact with a paper version of the user interface that is being tested.
A Facilitator: Usually a usability professional and his/her role is to record the issues raised during the meeting. Where necessary, the facilitator needs to probe into the issues raised so that these are well documented. Since the ideas of the people present may be conflicting at times, the facilitator needs to act as a mediator between the different parties.
A Human Computer: This person (typically the lead developer or someone who knows how the system is supposed to work) manipulates the paper prototype so that it can provide the feedback based on the user’s interaction. The human computer will not explain or give hints to the users about how the interface is supposed to behave so that the users are left entirely on their own to perform the tasks that they have been assigned.
Observers: These people are typically members of the development team. Their role to observe and interpret the users’ interactions with the paper prototype.
If you read up on user testing you'll notice that the only major difference between a paper prototype and a computer prototype is that a human is flipping paper around, rather than a computer flipping screens. All the other participants are the same!
