As can be expected, after working on five separate design projects throughout the term, I have begun to develop my own process for designing. After all, while the specifics of designing something are highly dependent on what medium is being designed for and the particular goals of the project, the general basis of the process remains the same. Below, you can find the major steps and tips that I have found helpful throughout the term, and that I will continue to use moving forward in my carreer.

1. Brainstorming

At first, this part will probably seem obvious. Of course you or your team are going to brainstorm for ideas on any project. However, my point here isn't just that brainstorming should happen, but also that it has to be done well. Properly done, brainstorming should explore the entirety of a design space. Write all of your ideas down, and try to fill a page or two. Coming up with many ideas and then combining them will only give your final product more depth, and projects where the brainstorming phase stops after one or two ideas have been generated will often be lackluster. Below you can see my brainstorming for ways to visually represent data. Many pieces of the various ideas eventually made it into the final version of the Design for Understanding Project.

2. Consider the Users

This next is by far one of the most important facets of Human Centered Design. Simply put, as a designer, you should always consider what does and does not make sense from the viewpoint of the users. This thought process is what should be used to narrow down the ideas generated during the brainstorming phase in order to generate a prototype. It's important that this happen even before any actual user testing is done. You don't to waste valuable user testing time on large, glaring issues that you could have noticed yourself. Finding these problems before will keep your testers from being frustrated, and allow them to pick out finer details for you to fix. An example of doing this is when my team was creating an application to refocus users when they are using attention, we used a fairly large threshold for how long they looked away from the screen in order to prevent false positives. Another example is when I was designing a webpage for use by the elderly, I made sure all interactive components were large and colorful, just based on preliminary research about designing for the demographic.

3. User Input

Now that ideas have been generated and narrowed through the first two steps, it's time to start getting user input. The importance of this phase cannot be understated. Even though you thought about the users earlier, you could easily have missed some details. Or perhaps, you just need to fine tune your application to keep users interested, and not frustrated. Either way, user input is necessary. There are a couple of ways this can happen. The first is user testing. This is the most important, so it is likely that you will end up doing this no matter what else happens. There are many sources on various methods of conduting user testing, and they all work well depending on exactly what you are looking for, so I won't fill this space with details about that. Instead, I will just emphasise the importance of integrating the ideas you got from the testing into the final product. After all, what's the point of user testing if you aren't going to listen to the users?

Another type of user input that I have used during the term is surveys. These are useful while you are still ideating, in order to further narrow down precisely how your application will interact with the user. For example, when working with a group on a chatbot that helped solve issues with group dynamics, I helped develop a survey asking our peers what experiences they had had with bad group dynamics, in order to narrow down basic categories of problem for our chatbot to handle.

4. Implementation: How do you feel about it?

After all of that ideation and testing, it's time to actually implement your design, building the final product. The build itself should be the simplest part, at least from a design standpoint, so the important consideration here is what happens after the product has been built, but before it needs to be demoed or released. For me, what happens is I look through the build, explore all of the functionality, and ask myself, how do I feel about it? Does it work how I expected? Do I like the way it looks? Am I happy with this as my end product?

Essentially, this is a form of final quality control. If you, as the designer, do not feel happy with your work, and cannot take pride in it, how can you expect others to enjoy using your product? Even the aesthetics matter here. People are less likely to like and enjoy products that, bluntly put, do not look good. As such, if you finish building, and you aren't happy with the results, it's time to take a step back, and try changing some things. In really drastic cases, you might even have to restart a step of the project. The important part is that if you aren't satisfied with your work, you aren't done.

The other side of this is that when you are happy with your work, be proud of what you have done. There is still more to go, but you should nevertheless be happy with yourself. By far, the projects that I have enjoyed working on the most are the ones where, even if it was a challenge, I reached an end product of which I could be proud. An example of this would be when I was designing to explore the potential of virtual reality. Although the project I worked on wasn't the most ambitious out there, it looked clean and polished, and did everything I wanted from it. I was proud of my work, and it was well received pn demo day

5. Where to go from here

By now, you've finished building your product, you like it, you've demoed or published it, and you've probably received feedback, both positive and negative. Even now, though, you still aren't really done. Design is a process, and it never really ends. You can use the feedback you got to make your product even better. You can move beyond the feedback, to extend your product in ways that, while addressing criticisms you may have received, transcends what those giving you feedback may have pictured. For example, for the Design for Wellbeing project, my group created a simple prototype of a webpage with some text to read, that would signal to the user when they are losing attention in order to refocus them. We received a lot of feedback saying that people wanted more options to read, and more visual interest on the page. While we could address the feedback in the simplest way, by just adding more options to the webpage, and using a style sheet to make it more appealing, the option we would have chosen to pursue had we more time would be to make a chrome extension with the same functionality as our webpage. This would answer all of our criticism, but in a way that the people who we had demonstrated the page to had likely not thought of. The point here is that sometimes it takes looking above and beyond what your current project is to really move it forward.

So there it is. My five step design process. Except this isn't really the end. This process evolved over the course of all of the projects I have done so far, and it will continue to change and grow as long as I am working in design. It will become more detailed as I become more experienced, and might even change completely as I try to apply it to various mediums that I have never encountered before. In this way, it's rather like a design project itself. Nevertheless, it will serve as the basis and foundation of my future design work. For that purpose, I am happy with it, and so, according to my own design process, it's ready to be used. Thank you for reading.