The Design Manifesto for Human-Computer Interaction
To wrap up my experience in Human-Computer Interaction (HCI) and my time with Professor Peck, I am writing this story to reflect on this semester of HCI and how it has impacted my own philosophy on design.
Oxford Languages defines computer science as “the study of the principles and use of computers.” I personally view computer science as how we can use computers to solve our problems and the problems of others. So many computer science classes look at how to solve problems on a very technical level, where professors discuss the advantages and disadvantages of certain algorithms and data structures for a given use case. HCI instead focuses on another aspect of computer science: if computers are meant to solve our problems, then the interfaces we use to interact with computers are deeply important. It not only determines the effectiveness of a given solution, but it also has influence over the behavior of your users as well as their quality of life.
Every aspect of this class is about how to design things to be better suited for our users. I use the non-specific word “things” because this class taught me that design is not just colors, space, font, or other artistic choices. Instead, design is about solving problems, and therefore, wherever something is made to solve a problem, there must also be design. Naturally this means that computer scientists have to understand how to design creations for people to actually use, which means learning all about the design process. Even though all of the projects in class focused on different modalities, the same design process was used for all of them.
Step 1: Understand the Problem
Solving the problem is only one part of the design process. As designers, the first thing we need to do is actually identify the problem we are trying to solve. Since we are trying to solve other people’s problems, the best way to solve the problem is to communicate with the people we are working with and ask them what the problem they want to solve is. Amy J. Kho, an HCI professor at the University of Washington, said this can be done in four different ways:
- Secondary research
Each of these methods have their own advantages and disadvantages, so it’s important to diversify your approach when you are able to.
For the “Design for Others” project, we chose to look at the Pennsylvania State Parks website. We redesigned a mobile version meant for parents with small children (that’s another part of design, figuring out specifically who you are trying to design for). Since it was not realistic to go out and interview our target audience or send out a survey, we decided to do secondary research by using online reviews of the parks.
Keep in mind, rather than take the reviews at face value, it is important to hear what they say and identify the underlying needs. It’s just like what Henry Ford said,
“If I had asked my customers what they wanted, they would have said a faster horse.”
We highlighted key words and categorized them as positive or negative, and looked for patterns. What we found was that park-goers wanted the following: appropriate activities that will keep their kids excited, information about any expenses, what the weather will be like, and how to keep their kids safe. Once we understood what the needs of our users were, it was time to go on to the next step of the process.
Step 2: Ideation
Now is the time actually come up with ideas for potential solutions. At the very start of this phase it’s just about simple brainstorming. By yourself or with a team, generate as many ideas to solve the problem as possible within about 30 minutes or so. Don’t worry about whether you have the skill or technology for a specific solution. Don’t shoot down ideas preemptively. Just get as many ideas on paper as possible.
Once the brainstorming is done, then the process of narrowing down to a single solution can begin. Respectfully critique each other’s ideas and figure out which solutions are and are not worth further consideration. Discuss in vague terms how you might go about implementing your solutions.
One excellent tool you have for this phase is sketching.
A sketch is essentially the first iteration of a prototype you can make. You can get it created and critiqued within an hour. It may not look very pretty, but putting the energy into a high-fidelity prototype just so it can get rejected by a client is way too costly.
To be honest, the ideation phase is probably my least favorite part of the design process. My creative muscles simply do not get enough exercise and my peers can get an idea up and running much easier than I can. However, one lesson I learned that helped me out a lot is this: there’s no shame in using Google for inspiration.
For the “Design for Another World” project, we decided to create a building that followed its own set of strange, non-Euclidean rules. What we came up with ended up being really cool, but we didn’t exactly come up with it all on our own. Instead, our team drew inspiration from video games. We took a look at the games Hyperbolica and Antichamber. That’s where we learned about several mechanics we ended up using, as well as the importance of sound and simple visual design. The Hyperbolica developer even updates a devlog on Youtube, which we also studied and took full advantage of. As lots of very talented artists and creators take ideas from others, there’s no reason to feel bad about it as long as you are being honest about where your ideas come from. As the great Isaac Newton once said,
“If I have seen further it is by standing on the shoulders of giants”
Step 3: Making Your Prototype(s)
Next comes the time to make a prototype, which should not be terribly hard, since we already created a sketch of some type. This prototype will simply be the second iteration of prototyping we undertake. It will just be at a higher fidelity than the last one.
For prototyping, you have to keep in mind (and it’s quite painful to do so, mind you) that the purpose of a prototype is not to build something that more closely resembles the final product than the last prototype. Rather the purpose of the next iteration of prototyping is as Amy J. Kho put it:
“…the purpose of a prototype is to acquire knowledge, before you make a prototype, you need to be very clear on what knowledge you want from the prototype and how you’re going to get it.”
It is discouraging to have ideas shot down but sometimes when you get feedback you need to set your idea aside so that another idea may replace it. As an example, consider the “Wizard of Oz” demo we did for the “Design for Expression” project. We designed four visual effects for each of the four types of martial arts seen in Avatar: The Last Airbender.
Our initial creations can be seen on the left. They are all composed of circles, which gives them the advantage of making them all similar to control and move around the screen. However, when we demonstrated them for the demo, our users said that the elements were too similar to each other. We decided that some of the element effects had to be redone entirely. In the end, we replaced the earth and water effects with what you see in the image on the right. They may have been a little more difficult to control, but it ended up being what our users wanted.
Step 4: Is This Going to Be on the (User) Test?
Once the current iteration of prototyping is finished, it’s time to follow it up with user testing. Conducting a proper test on your prototype is a skill in and of itself. I find the best approach to be similar to the one recommended by Don Norman. Simulate the conditions in which the prototype would normally be used, don’t distract or interrupt the user, and after they are done, ask them some questions about their experience to get more pointed feedback.
One issue I have found with testing is that the quality of the feedback seems to be closely tied with the modality of the product.
The feedback we received with our “Avatar” prototype was much more varied than the feedback that was given for our DCNR State Parks mobile redesign. I believe this can be attributed to the modality of the two projects. For the mobile app, our testers were sitting down and clicking on different buttons. Some may find it hard to keep themselves engaged when using such a product, and this will be reflected in the feedback we get. However, for the Avatar prototype, users had to physically stand up and move their upper body constantly to use our product properly. As a result, users were much more engaged. That’s why when using the mobile app, our classmates gave lots of feedback about things like contrast and the color scheme. Whereas with latter product, feedback was much more centered on how it actually felt to use.
Step 5: Put it All in the Design Doc
In HCI, the final submission after each design sprint is the design document. The thing you always have to keep in mind about a design document is that you’ve already begun writing it as soon as the design sprint starts. For every step of the design process, you should keep track of the evidence of what occurred. Remember the ideas that didn’t get used, don’t throw out those old sketches, and keep track of each prototype you make.
When we were creating the DNCR mobile redesign, we even kept track of each color scheme we considered using. What’s the point of all of this you may ask? There’s a few.
First of all, it allows you to go back and take a second look at the process while you are going through iterations of prototyping and testing. Maybe you are not happy with your prototype and are unsure how to fix it. Analyzing the evidence you’ve collected up to this point may help you find the answer to your problem. Additionally, it may give you a chance to incorporate some idea that got thrown out previously.
Second, it gives those who are interested an idea of the process. Design is not just a process, it is also a kind of story that other people can look at for purposes of education and entertainment (an excellent example of this is the South Park documentary 6 Days to Air). Other designers may be interested in your project or even working with or hiring you, but just looking at images of the final product will not ever be enough. People need to see exactly what you did and the decisions you made.
Last but not least, it gives you the chance to reflect on the project and the process. Simply doing the work and getting the project out there is not sufficient for learning. By forcing yourself to collect evidence and write out documentation, you also get to look over the process and rethink it all for yourself. You identify what went well as well as what went poorly, and with that you realize the ways in which you can improve in the future.
One final thing I would like to observe is that the design process is much messier and much less straightforward than I have laid out in this reflection. In reality, our designs frequently go back and forth between ideation, prototyping, and testing. There’s always some way to improve the product; always one more prototype and one more test you could make to optimize everything just a little more. However, at some point you release the final product not because it is perfect, but because nothing will ever be perfect.
Overall, it would be very easy for me to recommend this course to others. It is a breath of fresh air in a computer science curriculum filled with technical courses and intensive math. The projects that Professor Peck assigns are all very interesting and thought-provoking. The days where we all go around testing each other’s prototypes are a lot of fun because each team ends up creating something unique. I think any student will find that the lessons about design are useful no matter what path their life takes, since design, communication, and teamwork are always present in any kind of situation or project.