Reliable Design Validation

One topic we covered during this semester that I found particularly compelling was the research instruments, as I thought they had the potential to be incredibly helpful when utilized properly. The single most obvious reason being that it largely expands the perspective of the designer, allowing for a more objective and effective design. The designer is able to understand to a greater degree the effects of the design choices they make if they have a knowledge base formulated by a community of specialists in the field. Everyone has a limited worldview, constrained to their own experiences and education, but by using research instruments we can pull these views together to create a more complete picture of the design requirements. I believe that we did not use research instruments to their full effectiveness though, as we could have had several different phases of instruments conducted. Each instrument could have different content/questions to be filled out during unique phases of the product development such as: pre-development phase, alpha phase (designer then implements changes from usability phase1), beta phase (after testing phase2), and the final product phase.

If a single person was to design a system without any input from the specialist community for which he was designing it for, then it lacks critical analysis and thus can fail to take into consideration important factors and industry standard solutions that only someone educated in the field may be aware of. It is important to note that these are issues that are beyond simple usability testing. Therefore conducting multiple instruments during development, and especially after testing, allows the designer to catch these niche problems much earlier and fix them accordingly.

I also believe that the research instruments could be more effective if we had split them categorically as specialists/general. This is because many systems also have a section that the general userbase interacts with, envision something simple like a “Payment” app that has two types of users Customer and Cashier, where the general customer wants to pay and the store personnel wants to accept payment — obviously they have different requirements so they require different design considerations. But at the same time, these sections should be designed together to ensure they integrate well and to promote communication so that the transaction is not confusing (such as Cashier A can refer to the same label as Customer B even though they are looking at different designs of the app). Even if there is no general userbase interacting with the design, it could still be helpful to have their input to serve as a control group for comparison and gauging consistency.

Overall, I found research instruments to be a very effective and flexible tool for designing both specialist and general systems. Collecting this sort of data is crucial to understanding the impact of any user interaction design decisions, and truly helps the designers grasp a more well-rounded approach to the solution.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.