Design leadership

Background

During my time with Google Hire, I took on the role as lead designer for Hire’s mobile app. I led design for about 1.5 years on this team, from to initial conception and research through through the beta launch. Our team mostly consisted of engineers, with a PM, QA, and one additional designer who was working with us part time.

As design lead on a newly formed team, I was also responsible for keeping the team motivated, influencing our team culture, and creating the team’s processes that would allow me to work effectively with product, engineering, and QA partners to build a strong user centered product.

This work sample is particularly about my work shaping and leading the team. You can read more about the design of the mobile app here.

Approach

1. Get to know the team

Spend time with the people on the team, build trust, and get to know what motivates and worries them.

2. Identify strengths and growth opportunities

Form your own point of view and also gather input from the rest of the team

3. Introduce experimental changes

Incrementally introduce small ‘experiments’ and see how they fit with the team.

4. Continually iterate

Create mechanisms for constant feedback from team members on whats working and whats not.

Getting to know the team

Its remarkably easy to get caught up in work from the get go, but a huge part of joining a new team is just socializing and building relationships with everyone I’ll be working with. One challenge with this team was that we were split between two locations (South Bay and San Francisco), making it a bit harder to get significant face to face time.

Despite this, I had 1-1 conversations with everyone on the team within the first few weeks of joining and tried to spend as much face time with them as possible to just get to know each other and build up trust. Our team mostly consisted of engineers, with a PM, QA, and one additional designer who was working with us part time.

Identify strengths and growth opportunities

Additionally, I learned during this time about the history of the team and strengths of key members which influenced how I approached things later. For example:

• I learned they were a team of strong engineers who already had a lot of experience working with each other and didn’t need a lot of structure to be productive.

• I learned the team was pretty demotivated after their last app got cancelled less than a month from launch.

• I learned they’d had somewhat of a contentious relationship with their last design lead, and were a little skeptical.

• I also learned that none of them had much experience with the design process before or thinking from the perspective of user journeys, but that they were eager to learn more.

Team principles

From this and other learnings, I combined what I learned with my experience of best practices for a team and came up with the following key principles to guide recommendations I’d make to the team. I also ran these by individual members of the team and the group to ensure they felt like these seemed useful.

1. Optimize for rapid feedback and iteration

2. Minimize formal process, using tight informal collaboration when possible. (Note this is not a general principle, just something that made sense for this team given the culture).

3. Encourage a sense of shared ownership over the end user experience

Introducing experimental changes

Over time, I began to work with the team to introduce experimental changes to help us grow, as well as help implement changes that other team members surfaced as ideas. None of these were framed as mandated changes, but rather experiments and ideas that the team mutually agreed to try and modify over time.

Launch and research plans

To start, I worked with our product manager to break down our launch plan into smaller, more iterative chunks to reduce risk and allow for more feedback and iteration. We were originally planning a single open beta launch, but I worked with her to break it into a four phase launch.

At each launch we conducted user research, gathered feedback, and made improvements before the next launch to ensure success before the full launch. For example, while the overall Trusted tester response was very positive, we also uncovered several key frustrations users were having that allowed us to make changes and fix them before the full app launch.

1. Trusted tester (~10 users)

2. Closed beta (~100 users)

3. Open beta

4. Full launch

In addition to research at launch, I pushed to create a culture of constant research and user focus. I planned and led over a dozen additional research sessions focusing on different areas and research questions we had over the course of the 1.5 years I was leading design. For each session, I ensured anyone from the team was able to join and observe to help give the engineering team a first hand view into the problems they were helping to solve.

Internal processes

Over time, I also introduced new team norms to shore up some gaps I saw in the team’s processes.

One issue that quickly arose was we didn’t have any structured way for UX and engineering to connect, either for the engineering team to review and provide feedback on new and early designs, or for me to provide feedback in implementation.

While over-the-shoulder checkins were able to solve some of this, I also started a twice a week UX/Engineering sync as a forum for feedback where both designers and engineers could present work for feedback from the group, with a focus on overall user experience (whether that ended up being a usability issue for me to fix or an engineering issue like performance). This gave us a regular forum to connect over any UX related issues and helped build a culture and expectation of high quality products from both UX and engineering.

Another issue was that we didn’t have any processes for self reflection and iteration as a team. I started monthly retrospectives to create a feedback mechanism for the team to continually introspect and improve over time. We had a simple framework of Start, Stop, Continue that we visited every month to address things that were working well or needed to be changed, and assigned owners to any action items that came out of it. In addition to leading to several significant changes, over time, this helped us foster a sense of psychological safety and trust among the team as we practiced sharing candid thoughts about how to improve things in a safe environment.

UX workshops and critical user journey audits

I also led some workshops for the engineering team on the basics of design thinking and thinking in terms of user journeys. Following the workshops, we did a series of joint user journey audits for the engineers to apply their understanding of user experience and think in a user centered way while improving the product. Each engineer was assigned a series of critical user journeys and tasked with auditing the experience and documenting any issues at each step.

As shown below, we then aggregated their analysis into a spreadsheet, creating a centralized list we reviewed together of all our critical journeys and any UX issues we saw. Finally, we identified items that we mutually deemed to be ‘must fix before dogfood’ to ensure we met the bar of quality we were all comfortable with.

This process helped create a shared ownership of UX with the engineering team. I deeply believe that UX in everyone’s job, and it’s a designer’s responsibility to help facilitate that across the team.