Being a new UX Designer of an existing product

When I joined Capital One by the end of April 2021, I don't know too much about AWS Cloud Service other than knowing it's one of the cloud services on the market. I also don't have a deep understanding of cloud security. What I do know is user research and design. My hiring manager mentioned it's normal to take a couple of months to learn. I also talked to other designers in the team and heard about the complexity of many internal-facing tools that are created for Software Engineers and Tech Leaderships.


I was invited to series of meetings to learn the product and the small ecosystem during the second week. However, the best way to learn quickly is to get our hands on it to some of us. I discussed with my manager to start by picking up UI design stories to familiarize myself with the dev team and the product itself, and my journey started from there.


The dev team needs UI design supports. There are tons of tech requirements in the backlog waiting for visual design solutions. As a UX designer who is also interested in research, I had lots of questions. For example, are these tech requirements align with user needs? If so, is this design backlog prioritized by user needs? Who are the users of this product that has been implemented for over two years? The answers from the team were ambiguous.


After meeting with the product team, I requested a working session with my manager to develop a high-level UX strategy.

Fig. 1 High-level Research and Design Process

Laying out the research and design strategy helps me identify my next step and have a brief plan to communicate with the prod and dev team. After looking into the relevant documentations and works, I decided to conduct contextual inquiries (empathy interviews) with users from all different groups that we already knew. The expected deliverables from the empathy interviews include a user persona of each group and user journey maps. Thanks to the tremendous corporate-wide buy-in towards research, I didn't have to use much effort to convince the PM and the Tech Leader to support the idea.


I created the research plan, looped in the PM and Tech Leader for feedback, and engaged them in almost every session.


Having the PM and Tech Lead spend 15-20 minutes to review the research plan with me help to:

  • Align the team with research objectives to avoid going off-topic

  • Discover gaps in the research plan by having the inputs from the stakeholders perspective

  • Familiarize PM and Tech Lead with the flow of the session to set expectations

Fig. 2 Empathy Interview Plan Template

About eight weeks later, I built the user persona of two user groups. I communicated the findings and shared the personas with the team. Those documents were also referenced when a different product team started their project.


Fig. 3 Persona

A couple months later, I was in a couple of persona workshops with an external research firm that works for a different product team. I realized the gaps between job title and responsibilities through the workshops, and I took a step back to revisit the personas I created before.

User journey maps are another deliverables I planned to deliver from the generative research. I stopped creating user journey maps after tried to present one journey map to non-designers. I constantly reflect on how to work with the product and tech partners. I quickly realized that journey maps could be quite a lot for the non-designers in the team to care. Also, journey maps may not be the desirable tool due to the complexity of this product and the constantly changing environment.


Fig. 4 User Journey Map

To ensure efficiency and effectiveness when communicating research findings with the dev team, I synthesized a list of JTBD from qualitative research data and aligned each design story with users' JTBD. If the design story does not align with any JTBD, I would ask the team to take a step back to conduct research.


Fig. 5 List of JTBD by user groups

I include the JTBD in the design story description, also explain the JTBD first when reviewing prototypes with the dev team.


Some benefits of using JTBD to communicate with the dev team:

  • Communicate the essential user information to the dev team without consuming too much of the dev's time

  • Help the dev team to associate user needs with design solutions and

  • Rationalize design approaches that the dev team can give constructive feedback

  • Improve the transparency among research, design, and development to build trust with partners


While conducting empathy interviews and synthesizing user data, I also worked on UI design stories to address immediate tech needs. I'll tell the story of how I moved from designing with tech requirements only to having user requirements to drive both design and tech backlog in a separate post.

18 views0 comments

Recent Posts

See All