Hack for LA: Homepage Redesign
Giving Hack for LA a new face
Hack for LA is a non profit organization that brings together civic-minded volunteers to build digital products, programs and services with community partners and local government to address issues in our LA region.
With a growing number of volunteers joining the organization every week, and a desire to get donors directly to the platform, Hack for La needed a new homepage to help them expand their platform in a way that would allow each of the website’s users to learn more about Hack for LA and decide whether they’d like to contribute to the organization.
Tools: Figjam, Figma,
Team: Product Manager, Developers
Role: Product Designer
How might properly introduce Hack for LA to the growing number of participants in the organization?
A New Face
Design Decisions
Like many other organizations, Hack for LA transitioned to remote work at the beginning of the pandemic in 2020. While Hack for LA’s projects were still LA based, there was now more opportunity for volunteers that didn’t reside in the LA region to join the organization and lend a helping hand. Within a couple of months, volunteers were joining from all over the world.
Hack for LA was one of several brigades under Code for America, but the organization started growing big enough for there to be opportunities for Hack for LA to receive donations directly to the organization instead of to Code for America.
We had three main goals in mind while designing the new Hack for LA homepage:
Communicate what Hack for LA has to offer and how people can get involved to our users
Present some of the new communities and projects that had been recently introduced within the organization
Resulting Pages
We designed a completely new homepage on which users would get a brief introduction to Hack for LA, the types of causes that Hack for LA is involved in, the projects that volunteers are currently working on, and the impact our projects are having. Users would be able to explore different sections of the homepage according to their interests and goals.
User Research
Determining Page Hierarchy
We set forth a research plan with some key goals in mind:
Generative Research Goals
Understand what (such as beliefs, financial motives, other incentives, values) would motivate donors, partners, advisors, and volunteers to get involved with HfLA.
Understand what different users’ priorities are when interacting with the homepage
Design Research Goals
Determine the hierarchy of information on the homepage
Determine how we should communicate what Hack for LA has to offer and how people can get involved
Understand design elements that Hack for LA is missing when compared to similar platforms
C&C Analysis
We looked at the homepages of other volunteer organizations to get a better sense of some of the more common features for the homepage of an organization such as Hack for LA. We discovered several items that were common throughout these pages that Hack for LA lacked
A brief mission statement about what our organization is and does
Info on the impact the organization’s projects have had
Images that help to convey the work that the organization takes part in and/or the impact it has had
A section that gives information about donating to the organization
Usability Testing (Original Homepage)
I conducted 5 usability tests with users on the current Hack for LA homepage. Although our team had assumed that we may not be able to get a ton of insight on the homepage as a whole, since it would change drastically anyway, we figured it would still be helpful to hear a little about the things that could remain on the new homepage in some way (such as some of the projects and a portion of our call to action at the top of the page).
Volunteers did point out some things that we carried with us into our designs:
In Hack for LA’s heading, we currently call for volunteers to join by saying “Can you design, write, or code? You can help Los Angeles live up to its full potential at Hack for LA” 3 of the volunteers felt like this can be interpreted as something that excludes those who aren’t in those fields (ux researchers, project managers, etc.)
Though all of the users felt like the current homepage is too long and requires a lot of scrolling, they liked the idea of being able to see at least some of the projects on the homepage
User Interviews
We conducted user interviews with a total of 12 volunteers (5 individually, 7 in a group session after onboarding). We wanted to know what convinced volunteers to join Hack for LA and what kinds of things they would expect to see on the homepage of an organization like Hack for LA.
The volunteers provided us with some insight into what their expectations were for a volunteer organization’s homepage.
10/12 of the volunteers learned of Hack for LA through word of mouth (from friends or from peers that are in the same field as them). 2 of them learned of Hack for LA from groups they are apart of (Slack or Facebook Groups)
All of the volunteers joined with the intention of growing their careers. They were interested in gaining hands on experience in a way that would allow them to build their portfolios, gaining team/cross functional work experience and networking
All of the volunteers also liked the idea of giving back to the community and putting their skills to use for a good cause.
All of the volunteers liked the idea of being able to get a brief introduction to what Hack for LA does on the homepage
Information Architecture
Reworking the Site Structure
We were working on other pages within the website in addition to the homepage. The organization created new initiatives which required pages where users could go to learn more about them. This all meant that we needed to take a look at how these pages would connect and where users should be led when they choose to explore the site from the homepage.
I worked with another designer on making the necessary changes to Hack for LA’s sitemap, as doing so would help us sort out the information that users should be presented with on the homepage before navigating to other pages.
Stakeholders wanted the primary purpose of this sitemap to be a point of reference for the team.
Ideation and Wireframing
Mapping Out the New Homepage
We already had certain homepage sections requested by the program manager to take into account. We used those requests in addition to our user priorities to create mid-fi wireframes that displayed the layout as well as some of the content that would be displayed on the page. We took this opportunity to play around with different designs of the same sections. We initially each came up with our own designs and later combined different sections of all our designs into the following homepage options:
As we iterated options, we struggled with figuring out the order in which we should place the homepage’s sections. To sort this out, we sat with 12 volunteers to get their perspectives. We learned that the overall preferred order was as follows:
mission statement
Excerpt of the projects Hack for LA is currently working on
The social causes Hack for LA works on
Info about the impact that Hack for LA’s projects has had
In addition to the order of page sections, we also wanted users’ insight on multiple design options for some of the sections. We were left with the following selections:
Next Steps
Conducting Further Research
Because part of the motivation for designing a new homepage was to give Hack for LA a more “official” presentation so that the organization could begin to bring itself out from underneath the umbrella of Code for America, we still needed to speak with another group of our user: Donors.
There was concern with interviewing potential donors who the program manager had contact with before we had an official homepage to show. The program manager was concerned that without an official homepage to test, donors may be deterred from donating directly to Hack for LA, which would in part defeat the purpose of designing the homepage in the first place. As an alternative solution, my team decided to use the volunteer insights for a working design of the homepage that can now be used to test with donors.
What I’ve Learned
Takeaways
Navigating the Unknown
With the previous projects I’d worked on, I’d grown accustomed to planning research and being able to reach out to each type of user to gather all the research we need before moving forward to ideating and wireframing. This project forced me to think about how to work around any bumps I come across when it comes to ux research.
Before jumping into what our solution would be, we spent some time exploring the problem space, which meant gaining a better understanding of how people go about making friends and some of the challenges they’ve faced while doing so.
Because our problem space was a large one, we narrowed our scope to focus on those who were interested in making new friends after moving to a new city. With about 20% increase in the number of people who have relocated within just the past couple of years, we moved forward under the assumption that this would be the scenario where people would come across the most challenges when making friends, as opposed to people being able to make friends through mutuals in a city they’re already familiar with.
We moved into our user research with the following goals in mind:
Understand how people currently go about making new friends
Understand what may stop people from making new friends
Understand the challenges people may encounter while trying to make new friends during the pandemic
Understand what people are looking for while forming new friendships
Understand how often people are attending events/entering environments where they have the potential to make new friends
User Interviews
Our team held a total of 13 interviews in order to better understand how people went about making friends after moving to a new city and some of the challenges that came along with that.
Some interesting points that came to light were that:
There were three scenarios where people found themselves in a new city: a new job, University, or travel abroad
9/13 of users typically met new people through mutual friends. They felt more secure in a new connection when it was initiated by someone they trusted.
6/13 of users liked going in groups, but didn’t like scenarios where they were the only person meeting everyone else for the first time. They preferred the idea of bringing a couple of their own friends as well so that they could have someone they were already familiar with.
8/13 of our users had already used other platforms to make new friends (e.g. Bumble BFF, Reddit, Meetup, Facebook Groups, etc.) with varying results. They found themselves frequently navigating obstacles such as
Uncertainty with regards to whether the person they are matched with have the same genuine intentions as them
Their conversations with matches fizzling out due to either party running out of things to talk about
Uncertainty with regards to whether the person they are matched with is actually going to follow through on meeting up
With these insights brought to the forefront, I developed a user persona because I found that it would be helpful to the product manager and developers on my team to visualize the pain points of our users in one place.
For the purpose of our project, we chose to focus on those moving to new cities due to a career. We found in our research that this segment had the most obstacles when it came to making new friends and were the least likely to be able to make friends through mutual connections, due to the fact that they didn’t know anyone in the city. University students had a foundation of peers who were interested in making friends and so their decision to use online platforms to make friends were utilized as an extra option as opposed to a primary outlet. Those traveling abroad often traveled with others whom they already knew.
Mapping the data from our user research allowed us to discover opportunities to build solutions that addressed our users’ pain points:
Present events in the area to users, categorized by potential interests
Allow users to see who is attending events
Have users give links for their other social media accounts, so that they would be able to learn more about a person and their background before potentially meeting up with them
Have users be matched/interact based on events. Users would be able to browse the profiles of other people they have been matched with to determine which matches they’d like to accept/move forward with
Provide conversation starters to help conversations flow. Users would have a topic to start with and won’t have to worry about thinking of things to talk about
Provide users with a way to see the attendance history of others. This would allow users to get a better sense of the odds of whether a person may follow through on meeting in person
Provide users the opportunity to connect groups when going out. Groups of friends would be able coordinate outings together
User Journey
While we had our user pain points, we still needed to be able to pinpoint where exactly in the journeys our users take while making new friends we could improve the experience.
To Build or Not to Build
Feature Prioritization
The solution: Giving people the ability to connect with others over common interests.
After brainstorming several ideas that addressed the problem we were aiming to solve, we ended with a few features that we felt would benefit our product before narrowing them down for our MVP.
As a user I want to create a personal profile on this platform and have it shared with others that have a similar interest/cultural background.
User can share his or her name, gender, cultural background, education level, occupation, pictures, physical profile, and common interests
User can delete their profile from the platform
As a user I want to be able to browse common and uncommon social event types to help filter and get more precise matches.
User can browse social events that are listed on Eventbrite if they are specific and unique in nature
User can filter events based on interests, availability and whether they want that event to be remote or in person
User can browse social events that are commonly done together as a group such as going to a martial arts gym
As a user I want to be able to communicate with this person prior to the date of the event to establish rapport and schedule a potential early meetup/call.
User can chat with their proposed match via text
User can put out a public status that says they’re committed to going to the named social event with the other group/person that they matched with
User can message fellow attendees on the platform to coordinate with one another before an event
User can speak with fellow attendees of an event using threads.
As a user I want icebreakers and other conversation starters on the platform (i.e see prompts on Hinge) to aid in starting the conversation and building rapport with the other person/party.
User can use a preset of prompts and icebreakers that they can either comply with or ignore depending on their disposition
Sketches and Lo-Fi Wireframes
Navigating a few Bumps in the Road
Once we had a few key features figured out, I moved forward with some sketches and then lo-fi wireframes to begin drawing out the solutions we wanted to get across.
Bump #1 - Scaling Down the Design
While the initial stages of our process felt like smooth sailing overall, it was when I began producing the low fidelity wireframes that we found ourselves needing to take several moments to re-evaluate our user flow and re-prioritize some of our features.
Was a calendar feasible for the amount of time that we had? Should we think about another way for users filter for availability?
How easy would this filter be to implement? Would this actually be more usable for users?
The solution
The incorporation of a full calendar could be moved to the “nice to have” category in exchange for a dropdown filter where users could select a date. Not the most ideal, but the switch would help preserve that time for the incorporation of our main feature: the comments
While the horizontal filters could be visually appealing, it would not be feasible for the amount of time we had
Bump #2 - Where Are We Going to Get the Events From?
At this point, the plan was to pull API’s from Eventbrite, so that the main focus on our platform would be on building the communication features for our users, but this posed a problem:
Our user research had told us that people valued being able to find out more information about those they would potentially meet with. They wanted to get a sense of the personality and background of the person they were speaking to.
This meant that we needed to gather some information from users and maintain that info on our own platform (i.e incorporate a bit of a sign up process). However, users would already need to have an eventbrite account in order to register for Eventbrite events, which meant that we needed to figure out how we were going to work out two sign up flows that users would need to undergo.
This problem ended up being partially solved for us, since our developers weren’t able to retrieve the necessary permissions for the API’s anyway, but now we needed to figure out how we wanted to incorporate events into our platform
The Solution
Dummy events. The developers were able to create a backend that would allow us to enter our own custom information for events. Once we’d sorted out how the product would function, proceeded to getting some insight from our users
Usability Testing
Getting Feedback on Our Wireframes
I led usability testing sessions with 4 people, with the following goals in mind:
Learn whether the current user flow makes sense to users
Identify any points of friction in the designs
Understand the paths that users are most likely to take while navigating the platform
Learn more about some of the types of activities users may be interested in participating in
Understand whether interest categories make sense to users
We found that:
The flow as it stood at that point made sense to users and felt intuitive
Users were fine with the amount of information they would need to include while signing up
The users typically participated in interests that revolved around physical activity, music, or food
Although users are interested in forming more genuine connections with others and making new friends based on common interests, ¾ of them stated that they wouldn’t comment unless they felt compelled enough about the topic to do so.
While the timeframe that we had made it difficult to really analyze what made users hesitant to reach out in the threads, our solution was to encourage users to engage with fellow attendees right after registering. We added a prompt to the confirmation window where users can respond to the conversation starter right after registering for an event.
As we gathered feedback from users, we encountered one more obstacle that required another quick pivot…
Bump #3
The threads that were designed during the lo-fi wireframes were not going to be as simple to incorporate as initially thought, so the original threads turned into a more general comments section, with the prompt adding a more conversational element to the experience
High Fidelity Mockups, Prototypes, and Developer Handoffs
Getting through the Final Touches
Style Guide and Component Library
Once we had planned our next steps in the process, I began building a component library and style guide as I moved forward into high fidelity mockups and prototyping
Thinking through Future Features
Next Steps
While the focus of this project was to create an MVP for our product, we did think about some things that we would do if we were to move forward with further expanding the product:
Threads
Since the original goal was to incorporate threads into the platform that would allow users to directly reply to each others’ comments, but time limits made it necessary to shift that goal, one of the next things incorporated into the platform would be this.
Full Calendar
For our MVP, we decided it was best to incorporate a date filter where users can select their availability, but it would be ideal to have a full calendar where users can see all the dates for a month at one time, instead of having to scroll through a dropdown filter to get to their preferred date.
Direct Messaging
For our MVP, we decided that people wouldn’t feel inclined to reach out to fellow attendees of an event before actually meeting up with them, especially considering that our user research showed that people sometimes had concerns about the person they were corresponding with not being who they say they are, we chose to emphasize a more public and casual way for people to introduce themselves to one another with the option to explore a person’s social media profile if they wanted to message them directly. However going forward, one of the features we would incorporate into the platform is direct messaging, in order to allow for people to coordinate with others if they decide they want to pair up with a fellow attendee for an event.
What I’ve Learned
Takeaways
Communicating with Developers Early and Often
On previous projects, I’ve worked with design systems which involved using the components and style guide for the team I was working on. This project challenged me to learn how to prepare assets for developers, including how to prepare notes that would help developers understand what certain aspects of the design should look like. I also had the opportunity to communicate with developers starting early on in the process, which helped with understanding how each of the decisions we were making would influence the development process
Advocating for my design decisions
On other projects I’ve worked on, I either worked primarily with other designers, and when I worked on projects that involved other collaborators (project managers, stakeholders, developers, etc.) a good portion of design decisions were advocated for by the design lead. For this project, I had the opportunity to gain some first hand experience with backing my design decisions with the research I’d gathered in order to advocate for the users.