Before class, I thought…

… of the design thinking methodology to be a stable, straightforward, can’t-go-wrong kind of process. You have a problem, you interview people, you brainstorm (ideally with plenty of Post-It notes and Google Jamboards), you prototype, you refine for a few cycles, and then you’re done. You’re guaranteed to end up with a product or solution that people will love and use. It’s a people-first, user-friendy method that can solve anything, from something as simple as how to reduce food waste at Arillaga dining hall… to something more major like redesigning a voting booth.

I did work with these experiences…

What worked?

Definitely the additional user testing, like the baseline studies, the intervention tests, and the assumption tests. Before 247B, I was used to just one round of interviews, often for the needfinding stage. Everything after that, refining the product was just a matter of gauging user heuristics and testing with fellow classmates. Which, as an introvert and someone who dreads recruiting users, I was satisfied with. I always felt though, that my work was missing something by not involving users at more steps of the design process. 

At first, the extra user testing rounds in 247B was a shock to get used to. I found the work of recruiting new users and interviewees for each testing round to be very difficult and exhausting. Especially at Stanford, students are busy and very hard to convince to volunteer time. I feel like each round of testing, our results weren’t insightful enough because the people we recruited were always short on time and didn’t have the capacity to fully commit themselves to the project. However, looking back, even though our findings felt like they were only scraping the surface of what we really needed to know, I feel that the extra insights and findings really helped my team and I refine our solution into something better than what it was before. I just hope that in the real world, it’s easier to find users who are able to dedicate much more time, energy, and excitement to the product. I think with that, user test findings will shape a better product.

Back to the multiple testing, I do think this kind of repetitive testing was important, especially when we were at a design step where we had to make assumptions, or a major decision in the solution architecture. For instance, when we were brainstorming solution ideas, we were required to first come up with some interventions, kind of like low-cost concepts of solution ideas, and test these to see which one worked better. Or another instance, when we were designing a Figma prototype, we had to list down what assumptions does this prototype make of users, and then we tested those to make sure.

What didn’t work?

At some steps of the design process, I felt like we were just going through motions. It’s usually the synthesis-related activities, when we had a bulk of raw data and notes from interviews and surveys, and we were trying to pull any insights or discoveries from them. Specific activities included creating empathy maps, sorting Post-It notes, or drawing a cycle diagram. It was hard to tell if these actions were moving us towards a good solution, because everything was so open-ended and up to us designers ourselves for interpreting and assuming.

I was taking CS 347 simultaneously with 247B (as did most of this class, I think), where we did a huge unit on participatory design and the designer-designee power imbalance in design. It as a fascinating unit, and it made me question if user-centered design is truly possible at all, when we’re constantly struggling with power imbalance in design. That imbalance could something huge, like a Stanford designer interviewing a farmer from a developing country, or even something small, like a Stanford designer interviewing a fellow Stanford student… There’s always a power imbalance, and unless the designee themself is treated as a teammate or design partner, the designer is always going to be making assumptions on behalf of the designee.

At least in the case of Palendar, I feel that a bulk of our team itself are designees too, since some of us are graduating Stanford soon. So during the whole design process, I was low-key keeping myself as the end user in mind, and because I was the designer and designee at the same time, working on Palendar was much easier, and I felt more confident that my design choices were moving in the right direction. However, I am aware that this won’t always be the case in real-world design projects. I’ll extend on this more later in this post….

Ethical considerations

Privacy, a huge part of Palendar

Palendar’s main functionality required it to access the user’s calendar, and accessing calendars of the user’s friends, and sharing those calendars with the user. 

We knew users would feel hesitant about sharing their own calendar, even with friends. In the end, we worked around this issue by deciding to show only user’s free time in their calendars, so any specific calendar events and details were still kept private.

However, this still leaves some issues, such as Palendar assuming any open space on calendar as free time: doesn’t take into account sleep, rest, traffic… 

Also, Palendar’s design makes it rather hard for users to turn down requests from people that they don’t want to hang out with. Even our “Decline Request” button is gray versus the bright blue “Accept Request. ” Though Palendar does encourage people to actively meet up with friends, I am aware that there will be occasions when people want to say no. For instance, I can imagine me bugging my sister “I see that you have so much free time! What’s your excuse for turning me down?” when in reality, she just wants to spend her free time hanging out with other friends. Hmm, maybe a way to take this into account is for Palendar to help users autogenerate “no” responses? Like “Sorry, I have an assignment deadline soon and will be busy for the next few days…” I definitely do realize that there will be occasions when users want to say “no” to a hangout request, and we need Palendar to respect that users will sometimes want to make that choice.

Now I think this… 

… that design thinking is not a cut-and-clear, straightforward process as I thought. Particularly the designer-designee power imbalance. Previously in this reflection, I mentioned how for this class, because I am both the designer and designee, I feel relatively comfortable and confident that my design choices are making a product that will work in the real world. But even then, I am just one type of user amid a sea of many types of users. Plus, I know that me being one of the end users won’t always be the case in the real world.

I think back to the principles from the 347 readings on participatory design. They will influence a lot on how I aim to keep my work as user-centric as possible: respecting and treating designees as partners, I think, is the main key. Yet, even then, that’s not always possible. For example, the farmer from the developing country may not have the time and means to invest of time and energy into being part of the project, or my Stanford roommate is too bogged down with 20 units of work to test our prototype…. Sometimes when people want something designed for them, they don’t expect to do the designing themselves.

Next time when faced with a similar situation I will…?

I still don’t have any answers to the dilemma above. But, whenever I do design work, I reflect a lot throughout the process on what it means to be a designer designing for designees. I still firmly believe that truly user-centered design means befriending, respecting, and bringing those I am designer for, onto the team, in a way that fits their capacity. How exactly  that happens, that will always differ, and likely require much more time than Stanford’s 10-week quarter. 

But once that kind of strong partnership is established, I can be confident that any insights, findings, mappings from any user interviews and testing will shape a solution that will benefit the user.