The true story of UXDI social, my first desktop prototype — a UX case study

A wireframe from my final prototype.

The prompt for my first project as part of General Assembly’s UX Design Immersive course was pretty straightforward. I was asked to design a tool that would improve the GA student experience, either academically or socially.

Once I got going on the project, it quickly became clear that accomplishing this goal would not be so simple. What follows is a case study of the long and winding road — detours included — that lead to my UXDI Social desktop system, and a summary of what I learned from the process.

Deliverable: 5 minute presentation crescendoing with my clickable prototype

Project duration: 6 days

Business objective: GA wants to improve the current students’ experience socially because the education organization has a growth mindset and is always looking to improve.

Team: me

First Steps

With UXDI Social, as you can probably tell by the name, I decided to focus on the social aspect of the GA student experience.

My initial hypothesis: there could be an easier way for GA students, potentially of different cohorts, to get lunch together. This hypothesis was developed in collaboration with one of my classmates, Naomi Krenitsyn. From there on out, I was on my own.

The biggest assumption here was that students would have a more favorable experience of GA if they had an easier time socializing with their peers in different classes and programs. I was also assuming that students would want to meet new people during lunch.

Research Begins

To see if I had any idea what I was talking about, I began doing user interviews with 3 UX students going to school at GA’s Manhattan campus for 7–10 minutes each. The interviews were conducted on campus, and I asked my patient interviewees about 15–20 questions about their lunch, socializing, and lunch-socializing preferences.

From there, I figured out my target audience: UXDI students at GA NYC. (GA has campuses all over the globe, so specific location is important, and the organization also offers shorter-term UX programs — those UX students have different needs.) I proceeded by interviewing 2 more people from this demographic for 10–15 minutes, during which I asked 20–25 questions.

First Set of Insights

After transcribing these interviews, I started making sense of the resulting data through a process called affinity mapping. This helped me see the dominant trends in my users’ behaviors, preferences, and goals regarding the subjects relevant to my project. It resulted in four main insights.

1. Users were generally not familiar with the neighborhood surrounding GA.
2. GA students typically wanted to meet other GA students.
3. Users usually planned group lunches informally, planning around work.
4. They liked to eat lunch with friends from their own class.

Affinity mapping with post-its.

Time to Redefine My Hypothesis

Now that I had actually talked to some of the people that might use my hypothetical product, I had a better sense of what they were actually looking for. I was ready to articulate my research-informed problem statement:

UXDI students at the Manhattan GA location want a convenient way to meet one another socially, but don’t have much free time on campus.

How might we create more opportunities for them to more easily connect with one another given work-related time constraints?

I was also ready to decide on a success metric for my design. I chose the following:

If, during usability testing, all participants agree with the statement that “this improves the overall GA experience.”

Starting to Sketch My Solution

While students did seem interested in socializing with one another, quick lunches in the middle of work didn’t seem like a great time for strangers to become best buds. My plan: make a system that could function as a centralized hub for UXDI Students planning social activities.

I envisioned a desktop site where users could view, submit, and vote on events, combining the simplicity of a Web 1.0-style online calendar with the up-vote functionality of something like Reddit.

Early hand-drawn sketch of what became UXDI Social.

Making the First UXDI Social Prototype

Once I had experimented with some (very) low-fidelity designs to get a sense of what might work, it was time to start working on my first wireframe using the Sketch design software. My plan was to strike a balance between simplicity and effectiveness, so I decided to focus on one core piece of functionality: adding events to an online calendar and being able to attend them.

Sample Event for Prototype 1

Contact Form in Prototype 1

Let’s See if This Works: Usability Testing

At this point I had the beginnings of what would become my final design, so I asked some users from my target audience (UXDI students at GA NYC) to give it a whirl using a process called usability testing.

I asked 4 students currently taking UXDI course at General Assembly Manhattan to accomplish a pair of tasks using the tool: add an event to the calendar, and say that you are “Attending” an event on the calendar. Each of these tests lasted 7–10 minutes, and involved me asking 15–20 questions about the user’s experience of UXDI Social. In particular, I focused on whether they thought it was efficient and easily learnable.

If you can believe it, my prototype was far from perfect. The user feedback I received boiled down to four main insights:

1. Users told me that I needed to get rid of that awkward one-size-fits-all form for adding and attending events.
2. I had to replace it with an “Attending” button because that would be more efficient.
3. I also needed to create an option for users to purchase tickets for events listed on the site.
4. 2:4 users I spoke to also wanted to see who was going to which events, like on Facebook.
5. Make the “Submit Events” button more obvious.

After both hearing these critiques and observing some users’ confusion while navigating the system, it was back to the drawing board.

Some Improvements: the Second Prototype

With these users’ comments in mind, I resolved to improve my design.

Sample Event in Prototype 2

Submission Form in Prototype 2

Let’s See if This Works Part 2: Usability Testing (Again)

For the second round of usability testing, I interviewed people in a coffee shop near campus. The interviewees included 3 current UXDI students and a non-GA affiliated undergraduate student. Aside from the location change, the testing process was the same as the first round.

Here’s what I learned, again reminding me how important it was to understand how my system looked to the user.

1. Users wanted to see specific dates in the calendar, not just the event descriptions.
2. I needed to fix some error-prone buttons.
3. Users wanted a confirmation email to users after they clicked “Attending” on an event.
4. It was time to create a devoted Calendar page so users can see more dates than the days of the current week.

Implemented Changes, Next Steps, and Closing Thoughts

I tried my best to address these concerns in my third and final prototype, which you can click through here. Given the time constraints of this project, that was the edition of UXDI Social that I ultimately turned in and presented.

While it’s clear that the system improved since I began testing, it most definitely would need to get even better in order to be a workable product. My goal was to help UXDI students at GA NYC socialize with one another, and as my instructor Jayce pointed out, my tool would probably not replace Google Calendar (!) or some other more commonly-used service.

Nonetheless, this entire process was a really compelling learning experience for me. I had never really done any of these things before, and it was very cool to see how all the moving parts came together. Or, more often than not, how the challenges they presented gave me exciting new things to think about going forward.

As I stated earlier, my success metric was as follows: if, during usability testing, all participants agree with the statement that “this improves the overall GA experience.”

In my last round of testing, on a scale of 1–5 (where 1=agree and 5=disagree), users on average responded with a 2 to that statement. UXDI Social is on its way to being as efficient and easy to learn as possible, but it is not quite there yet.