Mini-Essay 3

Prototyping & Testing have been a somewhat interesting thing to explore, although some of the requirements have been a tad bit harder to achieve. That is a given because my group and I chose a non-tech path to take which has proved stressful, but has allowed us to try to fit our product into the frameworks and gain a better understanding of many of the concepts. Meme 1

Lofi vs Hifi Prototypes

This class is the first time I heard of the Wizard of Oz method of prototyping and is a pretty interesting one, but depicts the goal of a Low fidelity prototype. The method is also most suitable for software-based products. The general idea is that a participant in the testing interacts with the software almost like the final product, but instead of an actual full implementation, one of the designers/researchers is the one in control of the results/feedback from the system. This method and others like storyboarding and sketches are mostly aimed at narrowing down the situation of several solution ideas. This type of prototyping may also be useful in narrowing down useful features and also get some idea of how a user would want to interact with the solution/product if it were to be fully implemented/realized. (pp. 451)

On the other hand, high-fidelity prototypes are much closer to the final product and are often used in the situation where there is a need to conduct usability tests to further refine the product and utilize things like Figma and writing much of the code required for the software are often the go-to for tech-based products.

Low Fidelity High Fidelity

GP3

Generally, for GP3, my team focused on generating as many ideas, several being non-tech, generating simple Lofi prototypes for those using sketching and some storyboarding to better express features of the ideas that were generated, before filtering down to a single solution to continue designing. (pp. 447). Furthermore, our 1st iteration of the hifi prototype was in the form of a slide show, highlighting the components of the solution ideas we decided to go ahead with for our problem space surrounding hiking and climate change. In the second iteration, we added some Figma work to depict the website the users would likely need access to. But with GP4 coming, very unsure of how best to do the usability testing, given that our product is not a tech one, and that we as a team do not have the extensive ability to create intricate models that depict our vision. Realistically, I think we would need something similar to the iPad Usability testing testing case study from the textbook (pp. 555). But that level of work is not possible, so we will be reviewing our choices as much as possible and see if there are any tools that may help us get to a good state faster. GP3 has gotten us to an area of focusing in on an idea to create a solution with the problem space we had identified in GP1. I’d say we have made it well into the second Diamond where we develop ideas and prototypes to get feedback to aid better testing in the next stage. GP4 definitely be moving us closer to delivery, although we will not be implementing the idea per se.

Double Diamond

Through GP3 I also got to work a bit with Figma, and truthfully I was pretty surprised at how tough it actually was. I always believed it was somewhat hard, but not that it would take me a few hours to get the image below done:-(.

Figma

One major advantage of working in a group for GP3 is that the number of ideas we could generate was definitely wider than if it was just a single person working on the project. But along with this advantage comes the fact that sieving through some and designing quick designs proved to be a task, partly due to workload from other classes and also issues around scheduling meeting times as a team, so progress through GP3 was somewhat slow.

Teamwork

Thinking back to the throughline question “Is it possible for a system to be accessible and usable by all people?”, GP3 has furthered in my mind that it “almost” can, but requires allowance for lots of customizability, depending on the type of product. In our case, that meant allowing people to simply choose which of the hiking kit members they would need in their sets, but in terms of usability, our idea for the kit does not have something for those with other requirements, which is something I’d argue we should consider as much as possible as we move forward. But I’d argue considering everyone is hard, but aiming to do it is useful, as it would inevitably give more users a great experience with the products.

People please


References