Nextdoor Events: Client Needs vs. Wants
My first experience working with a design team to extend functionality of an existing product.
It’s also important to note that Nextdoor isn’t really our client, this is a mock client project drafted by our instructors to teach us how to work with a team and with a client who has an existing product.
Nextdoor is a private social media platform for neighborhoods with the goal of increasing community engagement between neighbors. Two of my colleagues and I were tasked with designing a service expansion on Nextdoor that will allow motivated community members to open their homes to host talks by influential individuals. The scope of this project includes the following:
- Initial planning phase (matching hosts and speakers together)
- Event set-up phase (some sort of invitation, RSVP, and ticket management)
- Attendance phase (maps and directions to the host’s home)
- On-going follow up phase (for periodically updating related content and hosting a discussion channel)
When we read the brief, we had a number of concerns.
- Why did Nextdoor want to create a Speaker Series?
- Did the current users want a Speaker Series?
- The ticketing system sounds like a huge project in and of itself.
- The existing event system isn’t noticeable and has a serious case of low engagement.
We also noted that Nextdoor has an existing set of core features offered in their current event system. However, most of these functions just “worked,” but nothing really stood out about it. So it seemed like the engineering and development was there, but the UX design wasn’t. That, and most users didn’t seem interested in it anyway from the current low number of events and RSVPs.
Unsurprisingly, our initial hypothesis was that a Speaker Series is the last thing that Nextdoor needs but, we all agreed that it would not be a good idea to make assumptions without research data. So we began researching how the existing system worked before jumping to conclusions.
First things first, we all went home to research Nextdoor as a company, what their mission was, and who their competitors were. We also all signed up for accounts and became active users to get a better sense of how the product works. This was so that we can get back together later with ideas already in our mind.
As a team, we brainstormed and came up with a set of 11 questions to ask current Nextdoor users about their experience with events in general and with Nextdoor. We also asked about their general experience with Nextdoor to understand what users are primarily doing on the platform. We had to be extremely careful with phrasing as certain words can lead or bias the survey results. We also wanted to make sure that the survey was short and easy enough for people to want to do it at all. After about about three rounds of feedback and discussions, we finally felt comfortable enough to send them out.
Empathy Maps & Speedboats
While we waited for survey responses, we got to work on figuring out any obstacles for users who want to host events, and users who wanted to attend events. We found this to be a hugely effective way to empathize with users, especially since we had 3 separate minds looking at it from different perspectives.
After reaching a good number of survey responses, we sent out an email asking for interviews. Unfortunately we weren’t able to get many to respond to the request so our interview data might be skewed. I actually couldn’t get anyone in my neighborhood to do an interview with my, but luckily I was able to get some good insights by interviewing one of my colleagues who told me she was an active Nextdoor user.
Since this was a 2-week project, we really didn’t have as much time as we would have liked to research. Our goal for the end of the first week was to have our research results synthesized and have some preliminary design done.
We took the results from our surveys, empathy maps, speedboats, and interviews (the little that we had at least), and slapped them all onto an affinity map. We then grouped together the results into categories, and extrapolated insights from them. The way we approached this was to make an argument of sorts, and use the results as our evidence to back up said argument.
By the end of the research synthesis, we had firmly established that there is a need for events, but a Speaker Series still didn’t make sense. Since we didn’t have any real means to contact our client and ask them why they wanted a Speaker Series, we made an assumption that we asked them anyways. The point in doing this was to figure out what the client really wanted out of the Speaker Series. After some time, we decided that Nextdoor’s goal was to increase user engagement and acquisition through increased event engagement. We created a solution statement to express the problem and how we intend to solve it in order to achieve specific user and business goals.
I did some preliminary sketching over the weekend to bring more emphasis to the current event system on the Nextdoor website. However, when my team got together on Monday, we decided to move forward with a design for the mobile app instead. This was because we saw that more users were using Nextdoor on their smartphones than they were on a desktop. We also wanted to tackle a mobile project design for the first time. At this point, I split up some sketch work with my teammate so that we can iterate faster. I came up with more designs to increase the exposure of the event system by incorporating minor design changes to the social feed and search suggestions/results.
Somewhere in-between the sketching and wireframing stage, we also got together and developed personas from the research results. We came up with 4 personas that described the types of users Nextdoor mainly deals with.
I wireframed in parallel with one of my teammates. I worked mainly my own sketch designs, but we got together to establish a style guideline that we should follow shortly afterwards. During the final stages, I finalized all designs to make sure that they had the same design styles to enforce that they are all part of the same application.
To verify some of the issues we are fixing for, I ran usability tests on Nextdoor’s mobile application with 3 of my colleagues. My test consisted of 3 tasks:
- Explore the app
- Find an event
- Create an event
From the exploration step, none of them explored to the event screen. When prompted to find an event, they were eventually able to find one, but it was not on their first try. Finally, when asked to create an event, none of the users created one through the compose button. One of the users showed discontent with the requirement to invite entire neighborhoods, and another could not figure out how to set a location properly.
When the deadline hit, we decided to draw the line and say that what we had was what we were going to present. We accumulated all our evidence that supported out hypothesis that the event system didn’t have enough engagement and went with recommended solutions on how to fix that. We also noted that the Speaker Series is possible, but will require a sharper UX design in the current event system.
What I Learned
I learned a bunch of new things throughout the duration of this project. I’ll just make a list below:
- Empathy maps
- Speed boating exercise
- Affinity maps
- Writing survey questions
- Research synthesis
So basically, we learned and practiced a bunch of user research.
I also learned that what the client wants may not actually be what they need. In our case, Nextdoor wasn’t ready for a Speaker Series, and I think that it was important to inform our clients if the project they want done doesn’t help them achieve their goals.