Introduction

It perplexes me how we live in a society where computer programmers are creating the systems that are changing our world as we know it, but they aren’t ever required to learn the basics of Human-Computer Interaction. This is not to say that HCI is necessary to successfully code functional software or that every computer programmer needs a complete mastery of the field. However, at least for me, even learning the basics of HCI has allowed me to view the software I write through a whole new perspective. Before this course, I didn’t think HCI was necessary for programmers, especially since there’s nothing that required me to take it. However, after taking the course, I’ve realized that we’ve not only learned invaluable techniques that give us tools to overcome design issues, but we have also gained a better understanding of design methodologies that allow us to get a stronger grasp of the people we are programming for. What scares me the most about all of this is that, before I had taken this class, I knew so little about HCI that I didn’t know what I didn’t know.  

This leads me to the work that I, and my groupmates, have accomplished over the last 3 months. During this semester we designed a mobile application that allows curators to both connect with and learn about the museum visitors that view their work. Even though it took us awhile to reach a seemingly simple design, we believe that our application could really make data useful so curators can better understand their audience. However, creating a good application would not have been possible without the methods we learned from UX design, so I want to share 7 of the most important learning experiences through our journey.

Teamwork Makes the Dream Work

At the start of this project, me, Kenneth, and Landon were randomly put together to form a group. However, by the end of this semester, we managed to become a team. What’s the distinction? A group is just a collection of people, but a team is a cohesive unit that cooperates to achieve a goal. As Katzenbach and Smith assert, “no group ever becomes a team until it can hold itself accountable as a team,” and the importance of this was probably one of my most stunning realizations (Katzenbach and Smith, The Discipline of Teams). From this process, I learned two very important aspects of working in a team:

1. Be Unnecessarily Explicit

When this project began, I figured work would be divided and we would just do our parts independently, eventually combining everything into a single deliverable. Even though our team contract emphasized communication, this was mostly in regard to any problems that had to be resolved. In terms of deliverables, we vaguely came up with “equal division of work, but also flexibility” as our focus. However, it soon became apparent to me that “equal division of work” was not so automatic.

One of our first assignments involved a contextual inquiry and a reflection (contextual inquiry check-in). However, none of us took the initiative to set up a meeting with any of our proposed users. After realizing no one had set up a contextual inquiry, we frantically looked around to see if anyone was free, and we were lucky enough to conduct a last minute interview with a WCMA curator. This allowed us to complete our deliverable, but we realized that we never wanted this situation to happen again. To resolve this problem, from that point on, we clearly labeled who was designated to do what part of each assignment. Even though we learned this through experience, this key takeaway was actually summed up from one of Pausch’s Tips for Working Successfully in a Group: “put [responsibilities] in writing.” Even though this may seem like an unnecessary step in working with groups, we learned the hard way that explicitly writing out responsibilities can prevent miscommunication of responsibilities from occurring.

2. Recognize Individual Talent

This is one aspect of teams that may seem too small or intuitive to deserve its own title. However, we did not actually delegate assignments that reflected our personal skills until way too late in our design process. Ironically, our team contract not only specified that we would delegate “based on skills or skills we want to develop,” but it actually listed some of our personal talents. However, for some reason, we never actually divided up labor based on these talents. Honestly, I took the initiative to do a large part of the planning (this was actually one of my listed skills), so this may have been largely my own oversight in not recognizing my own groupmates’ talents. However, I did eventually realize that Landon is extremely creative and fantastic at generating new ideas, and Kenneth is incredible at basically anything artistic-based, from storyboards to video prototypes. In the latter half of the semester when I actually internalized each person’s individual expertise, we started doing a better job of dividing the work based on these skills, making the overall design process much smoother. If I were to do a project like this again, recognizing individual talent is one aspect of a team that I would make sure to prioritize.

Quality Comes Through Quantity

This is one aspect of design that completely confused me until I actually experienced the process of doing it. Why would iterating over a bunch of mediocre prototypes be more effective than strategically planning and implementing a single “perfect” prototype? This leads me to a few more important points my group learned the hard way.    

3. You Are Not Your User

As a designer, your goal is to create something that your users need, but this is much easier said than done. One clear takeaway we learned was that you are not your user. This means your design should not be based off your own needs. However, this is only the beginning of the story. To create a truly useful design, you should not create what you think your users need since there can be misperceptions of what you think the user would find helpful. Unfortunately, you should not even create what your users think they need, since even they may not know what they want to use. You have to learn and understand your users, and then use this information to create something they actually need.

In our initial proposal, our goal was to “use the [emotional] responses people have to artwork in order to add depth to museum data files…[by not only showing] the “texture and personality” of a collection, [but also] the way exhibits make people feel.” Even though adding emotional information seemed like a cool idea, our first contextual inquiry with a curator indicated otherwise: “…audience emotion is rarely a criterion for choosing a piece of art since it is so subjective that it is too difficult to use as a measure of art quality.” This was a little disheartening as we realized our design idea wouldn’t actually help curators, showing how our lack of understanding of our users contributed to a false sense of what they needed. However, our last contextual inquiry was with another curator who said he worried “that people who are confused or frustrated aren’t expressing this.” He voiced his concerns regarding his lack of information about his audiences, which allowed us to pivot our design, giving us hope that we could actually create something useful.

4. Embrace Feedback

The example above is just one case in which we had to make significant changes based off of the feedback we received. In that situation, we had to pivot our design tasks. However, throughout this process, we’ve also had to make many changes to our prototype interface. The table below specifies just some of the changes we’ve implemented between the initial and final versions of our paper prototype:

Even though there were many problems with our initial design and we had to make many changes, the main takeaway here is that you should embrace feedback. You’re going to make mistakes when creating a design, whether that’s choosing the wrong color scheme, or forgetting to include some essential functionality. However, feedback directs your attention to these errors, allowing you to refine your design over multiple iterations. This is where you achieve a quality design through a large quantity of tests.

5. Sometimes Less is More

Through the many iterations of our paper prototype, we’ve realized that sometimes users do not want a lot of information. This is summarized by the simple and natural dialog heuristic where the goal is to present exactly the information the user needs at exactly the time and place it is needed. After conducting usability tests, we realized that an excess of information actually confuses the user, making it harder to find the information they are looking for. The first image below shows our initial paper prototype, while the second image is our final. As you can see, we found that our users preferred fewer screens with descriptive information rather than many screens with vague information. This illustrates how sometiems a simple design is more elegant than a complex one.

Accessibility & Ethics

6. Keep in Mind All Who May Use Your Design

When trying to create something useful, usually the designers have a target audience in mind. However, technology has become such an integral part of our lives, that it is important to consider your design’s accessibility to all, including those with disabilities. In Guidelines for Accessible and Usable Websites, Theofanos  and Redish discuss some reasons why accessibility is so important. First, it’s good business, especially since disabilities affect more people than you might think. Second, Theofanos  and Redish found that people with disabilities spend on average 20 hours longer online than non-disabled users. This means the Web plays an extremely important role in the lives of disabled individuals. For an in-class activity, we got into pairs where one person simulated a screen-reader and the other tried to navigate a webpage using only the information provided by that “screen-reader.” Being the navigator was actually an extremely difficult task, which illustrated to us just how difficult it might be for disabled individuals to use technology. Therefore, it is important for us to try to make their lives easier by providing a more accessible product. Finally, the last reason you should make your design accessible is because it is morally right. This topic of morals then brings me to our last important learning experience.

7. Shortcuts Have Consequences

As technology becomes more and more prevalent in our everyday lives, consideration of ethical consequences becomes increasingly important. During the early phases of a design, a product, or even a company, it can seem easy to adhere by certain ethics. However, as companies grow and start to become more concerned about profit, it becomes much harder to resist the temptations of taking shortcuts, leading to violations in ethical codes in the process. For example, consider Uber’s Greyballing tactic. After creating a ride-sharing service, Uber skyrocketed as a company. However, some regions banned Uber in an attempt to protect taxi companies from going our of business. How did Uber respond? Did they just adhere to this ban? Did they try to negotiate the ban with the authorities? No, instead Uber not only decided to ignore the authorities’ bans, but they created a fake version of the app in an attempt to evade these authorities. This illustrates how temptations for shortcuts and an emphasis on profit can lead to ethical problems. However, this is not the extent of the problem. As AI and machine learning algorithms develop, computers will be able to do more complex tasks. However, both morals and liability can become ambiguous. Uber’s self-driving car accident illustrates this situation as it’s hard to determine whether the car is liable, or the backup driver is liable. As a likely future user of this technology, I personally would not want a company lacking morals and prone to shortcuts to be the designer of a product that could cost me my life. If Uber is willing to evade authorities just to make it easier to profit, how will this be reflected in their AI’s desicion-making when it comes to life or death situations? This shows that we need to encourage a greater emphasis on ethics and the teaching of moral decision-making in the future of computer science.

Conclusion

These are the 7 most important lessons I learned through our design process. It was a great experience working with both Kenneth and Landon to create heART, and I believe we truly designed something useful. Regardless, we definitely had our fair share of prototype refinement throughout the semester, giving us many opportunities to learn practically the things we’ve discussed in class. Amazingly, many of the experiences I’ve listed here, like teamwork, are directly applicable to areas outside of HCI and even beyond computer science itself. Overall, this was a fantastic learning experience and I hope my discoveries have convinced you of the importance of HCI.