User Validation Report

Top Three User Needs
One of the team’s top priorities is the crafts simple setup. It is simply in both the prototype and
the real life-scenario. During the prototype creation, the team used dry fit joints so the crafts could be
assembled and dissembled within seconds with easy access to all the controls. In the real-life scenario,
the craft is a basic dragon, a saddle, for the skilled rider, and reins need put onto the dragon.

The second priority for the team is the crafts reliability. Every time the craft ran, it came close to
stopping in the designated area. It was within three inches on either side of the destination.

The third prior of the team was that it could blend into the environment. For the prototype, it is
a small craft that could be taken apart and placed neatly into a box. For the real-life scenario, once the
dragon was in the sky it would appear as a simple bird.

Validation Method
In order to gain user feedback, the team would display the craft itself and demonstrate how the
code works. The team will explain the overall purpose of the craft to the users and explain why we have
taken up the challenge of this project. The users will then be able to have the entire background and
have access to all the facts. The users will be ale to see loopholes in the team’s previous plan. The users
will be able to provide the team a new person of eyes and an outside look from consumers. The team
will ask the “users” about their opinions on the craft’s actual appearance. The users will be able to
provide accurate and beneficial tweaks to the overall design. The final step the team will do to try to
receive feedback would be by describing the actual code in simple, easy to understand words. This will
allow the users to provide new coding ideas and aspects. This will allow the team to determine whether
or not they are over-complicating the code.

Validation Results
To identify our results, we did a follow up interview with three of the individuals that were
involved with our initial interviewing process. One of the individuals loved the look of the dragon and
thought it was a unique and cool design. However, they thought that the code might work better if the
team took out the breaks and simply decreased the speed of the craft whenever the team wanted the
craft to slow down. The team did not take this individuals advice for that fact that their code already
worked very well with the system they already had in place. If they were to take the suggestion by the
user, the team would have had to redo their entire code which would take a lot of time and could cause
a lot of errors. The next individuals could see nothing wrong with any part of the teams’ plan and loved
every bit of it, except said the craft did wobble and might need more stability. The final individual
thought appearance wise the dragon could have larger wings to make the body more proportionate. The
also thought that adding a tail would be more aesthetically pleasing; they did not like the team’s idea of
using the caboose as its tail. The third individual also thought that the real-life scaling could be a little
more exact. The team took all of these aspects into prospective and were very pleased with the
outcomes they received.