Front Conference: 3 Key Takeaways

What I loved about attending the Front product conference in the “Silicon Slopes” is that it helped to expand my thinking beyond the bubble of just my product team and company. It showed me how other teams handle similar problems. Throughout the 14 talks given, I found there were 3 key takeaways that were a common thread across many talks.

1. Design for everyone and embrace edge cases to make a product better & differentiated from competitors

The speaker that truly embodied this topic was Benjamin Earl Evans, the design lead of Airbnb’s Anti-Discrimination team. Airbnb put together a cross-functional team to solve discrimination problems that were coming up through the use of their product. This team takes into consideration all types of users (hosts and guests), inclusive of different races, religion, gender identity, age, disabilities etc. Benjamin highlighted that because of the nature of their product, failure in their case is not just a drop in metrics, but could result in a hate crime — for example, hosts not wanting to rent their home to certain people because of their race. This was a strong statement that stuck with my colleague and I because it made us think of the more widespread impact our products can have beyond it’s surface level function.

Product teams tend to build for the majority audience that will use their product, but by doing this they leave out a lot of potential users. Benjamin made some great recommendations on how to approach designing for diversity that I would like to integrate more into my design process. Firstly, it’s important to align design decisions with business needs, because realistically just good intentions will not be enough to convince key stakeholders. From a product designer standpoint, this perfectly aligns with my main goal of balancing user and business needs. At the end of the day, our company’s primary objective (as with almost all companies) is to increase revenue. By designing a product that is more inclusive, for example making sure that a ticket checkout flow is accessible to all, will lead to an increase in ticket sales which means higher revenue for the company I work at. In this way we are not only ensuring a wider audience is able to use our product, but we are meeting our business goals.

The second piece of advice was to not be afraid of challenging our users. It’s easy to be afraid of making major changes to a product that has been around for awhile because users have become accustomed to a certain workflow. Even if not ideal, users have adapted through repetitive motion and we wouldn’t want them to be disoriented by significant changes. But this mentality prevents innovation. Often when products are first born, they are created for just the main audience because of limited resources and an urgency to go live. But once a product shows success, it’s essential to keep optimizing it to be more inclusive of edge cases that were not considered in the upfront. And yes, this will require some relearning on the part of the current audience, but in the end can lead to a much bigger pool of users. And while the transition can be difficult, there are methods that can be put into place to make it easier, such as partnering with customer success teams to communicate these changes to users, using onboarding to educate users and testing changes with current clients to ensure they are still able to complete their day to day tasks.

The last recommendation was to seek out diversity and ask ‘who’s missing from the room’? Because only then can we truly think through how we’re meeting the needs of others. While product team members can use empathy and research to imagine the scenarios different types of people experience and how that impacts their interactions with a product, unless you have a diverse group of people who actually represent those you’re designing for, a team can’t truly understand all the nuances that should be taken into consideration.

An example Benjamin walked through that reflects this is that when people with disabilities search for a place on Airbnb, the features that are a priority for them are quite different than someone who doesn’t have disabilities. By adding a team member that has disabilities and can authentically speak to what those challenges are, they are much more informed and can solve the problem much better than if a group of people without disabilities designed just based on their assumptions.

While it’s rare to find a team that is perfectly diverse, if a company actively works towards that as a goal, it shows that this is a priority for them and will lead to a more inclusive product. While Airbnb still faces discrimination challenges, the fact that they have a full team dedicated to anti-discrimination that includes people from different facets of life shows they are truly working towards an optimized solution.

2. The importance of different types of research

I was excited to see that many of the speakers highlighted the importance of research in the design process. UX research is in the place that UX design was a few years ago, where companies did not fully understand the value and importance of it. One of the key points that many speakers focused on was not only the importance of research, but knowing when to use what types of research. In sum, quantitative data helps us identify gaps/opportunities, qualitative data allows us to understand why these gaps/opportunities exist and intuition, which is not in itself a type of research but can be informed and validated through research, helps us decide on solutions. A great example of this was presented by Vicki Tan, a product designer at HeadSpace, who spoke about how research informed the onboarding flow for their app. Their quantitative data showed that there was a big user drop off at the onboarding step where users were asked to do their first meditation and their weekly retention rate was not where they wanted it to be. Based on just the quantitative data, their team redesigned the onboarding process, but because they didn’t truly understand why users were dropping off and not continuing to use the product, their new design helped with drop off but did not help with their ‘week 2 retention’.

From here, they decided they needed more in-depth research so they used qualitative research tools such as diary studies and surveys to get a deeper understanding of their user’s goals, motivations, and behaviors. While this qualitative research helped to define the pain points users were experiencing, they found that they were getting different responses that didn’t lead to a singular solution. This is where they ended up using their intuition to help them make their final design decisions on a revised onboarding process, which led to a 10% increase in retaining their users. This case study is a great example of how each form of research was important and led to the final successful onboarding in different ways.

There are a lot of teams that don’t prioritize research as part of their design process because they claim there isn’t enough time, but doing research upfront to validate a product or feature before it goes into development makes it significantly easier and cheaper to make changes based on user feedback during the design phase rather than waiting until it’s developed. I have seen many cases where teams did not use research in order to save time and money and ended up spending months backtracking to redo an unsuccessful product or feature that could have been prevented. While I understand that there’s always the limitation of deadlines and budgets, there are ways to fit in guerrilla research tactics, even if it means grabbing a few people off the street to do quick usability testing. Fortunately, the product team I work on understands the value of research and it’s an essential part of any project we work on. Through interviews and usability tests, we ensure that the features we plan on developing solve a true problem, that we’ve considered all the edge cases and that our designs are usable and enjoyable.

3. Involve the full team every step of the way

The last topic that came up a few times was the modern customer-driven product team and how the different members, inclusive of engineering, design, and product, should all be involved at every stage of a project. I fully agree with the 2 key points from the talks that support this, as my team has already implemented this and found the same successes. Firstly, that bringing engineering into the research process helps give them empathy, context and urgency (Brian Crofts, Chief Product Officer, and Adrienne Gajownik, Senior Product Designer, of Pendo) and secondly, that having the team in the room together allows for on the spot alignment and prevents the communication waste that happens if only some of the team is involved with research and has to relay it to the rest of the team (Aryel Cianflone, UX Research, of LinkedIn).

My team recently worked on a project to build out a new feature that was quite complex and had many moving parts. I created the initial designs based on user requests we received in the past and the usability tests I conducted to get feedback on these designs included myself (product designer), the engineer that would be building it and a product manager. By having all of us listening to the user’s feedback in real time, we were all clear on the user’s pain points/needs and were able to ask the users direct questions. We did quick recaps following the tests to discuss the feedback and align on the insights. This was efficient and led to us all being clear on how to move forward with the design and development of it. Because each of us came from different specialities, we were able to each ask unique questions to the users and were able to think of creative solutions to the problem we were solving.

Hearing that these were the main topics being discussed validated the processes my team working on the OvationTix product have implemented and I’m excited to amplify these efforts with the suggestions made by the speakers. Being in a community of product people just as passionate as I am was inspiring and I left with a more robust toolkit filled with strategies on approaching a wide range of problems.