My HCI Design Manifesto
By Brian Gourd
In this article, I reflect on the projects and principles from my Human-Computer Interaction course at Bucknell. I will share my takeaways from the course and how my experiences in it have helped shape my design process into something unique to me.
Designing For Human Interaction
When discussing the design process, it’s first important to understand what exactly we mean when we say Human-Computer Interaction. In previous courses, I had always been given projects with a clear guidelines for a final product, without needing to really think about the end user. In reality, thinking about the end user is something that should be taken into account throughout each step of the design process, as they are the audience which we design for. This end user makes the “human” part of HCI. The “computer” part of this term really encompasses and computer-based technology that exist, such as smartphones, gaming consoles, smart fridges, and so on. Finally, the “interaction” is the part of this term that really describes the goal of HCI. Interaction describes how we use devices; is it based on keyboard inputs, gestures from video input, sound input, or something else. Creating an appropriate form of interaction for a product is central to designing for people, since they’ll have to deal with that every time they use the product. By bringing these three parts of the field together, we can form a general definition for designing for HCI. The HCI design is a process that takes into account the needs and wants of the end user in order to create a product or service that is built specifically to benefit these users. By centering the design process around those who will use the product, designers aim to create something which is natural for people to interact with and aims to solve the issue for the audience they design for. This is all centered around creating an appropriate modality of interaction which both solves the issue it set out to solve as well as feeling natural and easy to use for the intended audience.
My Design Process
When designing for human interaction, it’s extremely important to follow a structured process to guide your research and design. While this process can look different depending on what your designing and who you are designing for, it still should follow the same five steps: discovering or observing a user need, defining the problem surrounding it, designing your implementation, testing it and iterating on it, and finally implementing and evaluating your design.
Discovery
As the first step of the process, discovery is also the probably the most overlooked. However this step is extremely important since it allows for the designer to better understand user or client needs before they even think about a solution. This step also oftentimes gets clumped together with defining the problem, but it is more effective when we take a step back and understand a user group and research topics before we jump at a problem to tackle. By doing this, we get a more in-depth initial understanding of all factors contributing to the problem for later steps of the design process. In the image above, we can see how this step of the design process was implemented in our Design for Others project. Before our team even defined the problem within the website we worked to redesign, we first needed to understand the needs of the group we were designing for. In this instance, this step of the process was extremely important since nobody on our design team had ever needed to rely on features built for assisting individuals with disabilities. On other interactions, such as the VR environment we designed in a more recent project, this step of the process was less critical since we also fell into the intended user group. One takeaway I found from this step of the process is that only so much research can be done about a user group before it becomes repetitive or detached from the project. I find that it’s very important to get an initial understanding, but it isn’t the worst thing ever if you find yourself needing to go back and conduct more specific research after your design goals become more defined.
Defining The Problem
“We can’t define them fully, but we can try.” — Oxford English Dictionary
After getting sufficient information about your user group, the next step of the process is defining the problem. If the initial step of researching was done to an appropriate degree, then this step should come pretty naturally. After getting an understanding of the needs of the users you choose to design for, as well as the technologies that already exist, you should be able to define the problem. The problem in this case would be whatever disconnect exists between the user needs that should’ve been discovered in the first step and what is already being provided by existing products or the implementation you are redesigning. By looking at these disconnects, the problems make themselves clear to the design team. For example, when my design team worked on redesigning the Lewisburg Children’s Museum’s mobile interface for users with disabilities, we recognized that a common issue that this user group experienced was complexity of an interface. While many designers feel a need to create complex designs which can display lots of information, it actually ends up turning away these disabled users who may be reliant on instruments such as screen readers in order to navigate. To make up for this issue in the case of the Children’s Museum’s website, we defined our problem as being the complexity in navigating the site. While this isn’t an issue doesn’t exist for all users, when designing for human interaction it’s important to be as inclusive as possible in our designs. A take away from this step of the process is that problems are specific to the user you are designing for, and may not always be obvious to the designer without an in depth understanding of who they design for. Additionally, not all problems can be solved, so it’s good to break up user issues into what is more possible to solve and what seems like a stretch. Trying to solve all of a users problems within a certain context can leave the designer unsure of where to start, so it’s important to be as specific as possible when defining the problem.
Designing
With our problem defined, we can finally begin to work on designing solutions. One take away from our HCI course within this step is that it can really be broken down even further into ideating and prototyping. Firstly, before we even try visualizing our design in any form, we come up with ideas. Ideating is crucial to this step since it allows the design team to collaborate and bring in their unique skills which may bring ideas to the table. I’ve found from my experiences within our class that when ideating it is beneficial to aim for quantity over quality. Ideas don’t need to be fully fleshed out yet (although it’s even better if they are) and just because something seems farfetched doesn’t mean it should be omitted from the ideation process. Oftentimes, these farfetched ideas are actually really helpful since they lead to discussion within the group and sometimes give the team a new way of looking at the problem. For example, when ideating with my team for the VR environment we designed, I had been thinking it would be really cool to recreate the underwater city from the game “Bioshock”. While this idea was realistically too grand for the time frame of the project and skill sets of our team members, it got us thinking about how an underwater environment may be implemented, as well as what aspects of this city may be possible in our design. From this “crazy” idea, we were able to come up with something more concrete and obtainable, and it ended up shaping our final design.
After the design team fleshes out as many ideas as possible, they should move onto prototyping their top ideas. Similar to how researching and defining the problem can often be incorrectly combined into one step, the same happens with ideating and prototyping. Prototyping an idea takes longer than coming up with it, and if we tried prototyping every idea from the ideation process we could be stuck doing it for quite a while. So when these steps get combined, it usually leads to not as many ideas being discussed, which can take away from your final product. I’ve found that the process of prototyping can also oftentimes be broken down even further into first sketching and then creating more high-fidelity prototypes. Sketches are quick drawings of a potential solution and they are helpful as an initial visualization of an idea. By visualizing the idea in such a way, it can get team members on the same page and can also highlight its limitations. Getting on the same page as your team members is pretty hard to do without a visual, since we see things differently in our own heads, so sketches are very helpful since, while it is cliché, a picture is worth a thousand words. Finally, after a team has sketched their top few ideas from the ideation phase, they can combine the best aspects of their favorite designs into a more high-fidelity prototype. This prototype can help the team decide on more specific visual aspects of their design before they start building. When deciding on visual aspects of your design, I’ve found it important to follow the standard rules when it comes to layout and visual features. These standards exist for a reason and help stop designers from taking common missteps in the process. At first, I thought that the standards would limit creativity in my designs since they are strict rules on things like spacing, color, and contrast, but in reality there are plenty of other areas to be creative, and straying from the standards made for designs that were more difficult for users to interact with.
Testing & Iterating
With a high-fidelity prototype designed, we can finally do what we set out to do in the first place: build! Since the prototyping stage concludes with a single design that has elements already decided on, the initial build of the implementation should simply follow that model. However, no matter how fleshed out your prototype is before you start building, it’ll never be perfect the first time, which is where iterating comes in. Without iterating, it’s unlikely that your build will even work, since issues always seem to arise once we actually start to code. For example, when my design team was working on the Design for Expression & Creativity project, we had already decided on creating a YouTube player that could be controlled with hand gestures, and had an initial idea of what those gestures would be. In reality, when it got time to building, we realized that the AI models that recognized the gestures weren’t fantastic, and we had to look for a new software that could do this, as well as update the original gestures we decided on. Designers shouldn’t get frustrated when they need to make changes from their original idea, since each change brings them one step closer to a final product that meets your goals. Additionally, when testing your design, I’ve found it helpful to get input from users that didn’t work on the project. No matter what you create, it’ll seem easy-to-use for you since you created it, so it’s important to bring in an outside pair of eyes and hands to help you with testing. I would oftentimes show projects I had been working on to my housemates throughout the semester and it made me able to get useful feedback from people not involved with the project.
Implementing & Evaluating
Finally, once we have finished iterating on our design and believe that it solves the problem it set out to solve, while also being something that users can interact with with ease, we can begin to distribute our final product and evaluate it’s effectiveness. Evaluation of the product is key for determining if the problem is actually solved or not. Specifically, we look to have our final design evaluated by the user group we designed for, since it’s their needs which we aimed to bring them. While many people may think they are done once the “final” design is released, the process really just repeats itself from the design step. Even if the problem is solved with your solution, it doesn’t mean that your implementation cannot be improved upon, which is why evaluation is so important and why it is never really the final step of the process.
Conclusion
It seems like from each step of the design process, I found at least one major takeaway that I believe would help students designing for their first time. When researching your topic, it is important to ensure that you familiarize yourself with the needs of the users you are designing for as well as the capabilities of the technologies that already exist. When defining you problem, be specific so that you have a clear goal in mind for your final product, and don’t try to take on many problems at once. When designing, it’s important to keep separate the steps that go into the initial designs. Jumping directly into prototyping without first ideating with your team can slow down the process or leave you with fewer ideas than you should have. When testing and iterating, bringing in people who did not work on the project can help you find issues that may not be apparent to the design team. When you get close with a project, interaction with your design will always feel natural, so having outside eyes in can be pivotal for identifying issues. Finally, when evaluating your final design, its important to keep in mind that it probably isn’t truly the final design. Don’t be afraid to go back into the design process and make changes, as it’s the only way to keep improving your design.
