Enterprise UX at RBC

For the past two years, I worked as a product designer at RBC Wealth Management. I was fortunate to work in cross-functional Agile teams that deliver web and mobile apps for client prospecting, on-boarding and managing. To better provide a holistic representation of my experience at RBC, I would like to walk you through the following information:

1. Overview

   • Challenges

   • Product team and my role

   • Design process

2. Project Information

   • Project background

   • Users

3. Design process

   • Discovery

   • Ideation

   • Creation

   • Delivery

4. Lessons learned

   • Solutions

   • Reflection

Overview

1. What were the challenges at RBC?

2. What was the product team like? What was your role? 

Product Team Structure

Agile Product Team Roles:

• 1 Product Owner

• 1 Designer

• 5-10 Developers

• 1-2 Quality Assurance

• 1 Scrum Master

• 1-2 Business Analyst

As the only designer, I wore various hats including researcher, interaction designer and UI designer to help the team identify, investigate, and validate the problem, and ultimately design, test and ship the products.

3. What was your design process?

The process acted as a high-level guideline which was flexible to support various types of projects. To better show case the process, I organized the following project work into steps. However, it is fluid and not as linear in reality.

myGPS Project Background

1. What is this project about?

• Project background: myGPS is a financial planning tool which provided investment advisors a holistic view of clients’ wealth management needs and tracks progress towards meeting financial goals.

• Project goal: myGPS 2.0 is a redesign project based on the existing 1.0 version.

• Platforms: Desktop and iPad

2. Who are the users?

• Primary users:

  • Investment advisors

  • Associates

• Secondary users (future state)

  • RBC wealth management clients

3. How long is this project?

I was partially (30-50%) allocated to this project for a year.

Design Process

1. Discovery

a. Starting point: myGPS 1.0

• What were the initial challenges?

  • Usability issues: broken user flows, design debts, inconsistency etc.

  • Outdated UI: no design system

  • Need a lot more features

These were the initial challenges and requirements provided by the product owner based on indirect user feedback and assumptions. However, there was no factual user data to validate them. With these information in mind, I started design discovery phase.

b. Stakeholder interview

• How?

  • Conducted semi-structured interviews with business sponsors, product owners and business analysts

• Why?

  • To understand business goals (both short-term and long-term)

  • To determine success metrics, KPIs

  • To gather assumptions about the users

  • To gather information about resources, constraints, timelines and competitors

c. User research

• When to use which user research methods?

  • Purposes: behaviour (what people do) vs. attitudinal (what people say)

  • Types of data: quantitive vs. qualitative

  • Context of use: using/not using the product

• How?

  • Visited RBC branches and conducted field study by direct observation and contextual inquiry with users

  • Conducted remote task-based usability testing: tested two major flows with 5 users

• Why?

  • To validate business assumptions with real users

  • To find out how people use the product today and the reasons behind certain behaviours

  • To capture the end-to-end user journey including digital, physical and human touch points

d. Empathy mapping/Current user journey mapping

• How?

  • Conducted empathy mapping and journey mapping workshop with the product team

  • Validated the outcome from the workshop with the users

• Why?

  • To understand users' goals, interests, pains and concerns

  • To identify the pain points and discover opportunities in the user journey

  • To synthesize the user feedbacks from previous user research

e. Reframe the challenges

• How?

  • Reframed the challenges into opportunities using "How Might We" method

  • Prioritized them based on impact and feasibility metrics

• Why?

  • To rethink the original challenges

  • To provide a frame for innovative thinking and allow for a variety of solutions

f. Comparable review

• How?

  • Scanned the comparable products from both inside and outside of the industry

  • Listed the strengths and weaknesses of their products

• Why?

  • To find out how the comparable products solve the variations of problems that we were solving, what's working and what's not.

  • To discover new technology and innovation to unveil the potential

2. Ideation

a. Brainstorming and prioritization

• How?

  • Came up with as many ideas as possible using divergent thinking methods

  • Combined similar ideas into categories and prioritized them

• Why?

  • "Shoot for the stars and land on the moon."

b. Future user journey mapping

• How?

  • Mapped out the future end-to-end user journey (Before, during and after interacting with our product)

  • Included all physical, digital and human touch points

• Why?

  • To understand how our product fits into users' day-to-day workflow

  • To simplify the workflow and provide value at each touch point

c. User flow

• How?

  • Determined all possible scenarios

  • Created user flow diagrams including user actions and app responses at each step

• Why?

  • To visualize the steps that a user takes to achieve a goal

  • To communicate with developers to make the developing process more efficient

3. Creation

a. Information architecture

• How?

  • Conducted card sorting sessions (remote and onsite) to create sitemaps

• Why?

  • To gather insights about users’ mental model regarding the information space

  • To visualize the skeleton of the product

b. Wireframes

• How?

  • Led the co-creation workshops with the product team

  • Created rapid paper and whiteboard wireframes

• Why?

  • To promote efficiency and transparency in the design process

  • To solve problems at an earlier stage and optimize the outcome collaboratively

c. Design system

RBC design system was another on-going project. I worked collaboratively with other visual designers to ensure that the design system supports various use cases.

d. High-fi mockups

• How?

  • Translated the wireframes into high-fi mockups using the design system

  • Created mockups for different states and edge cases. (e.g. blank, loading, partial, error states etc.)

• Why?

  • To establish the look and feel of the product

  • To address all the potential different states and use cases

Before redesign vs. After redesign

Different States

4. Delivery

• How?

  • Provided project information (goals, timeline and members of the team)

  • Delivered clickable InVision prototypes with Inspect function for development

  • Provided user flow diagrams and sitemaps

• Why?

  • To provide project background and context

  • To bridge the gap between design and front-end development

  • To demonstrate different scenarios and visualizes the structure of the product

Lessons Learned

How to fit UX in Agile worlds?

• Design must work at least one step ahead of development

  • Have enough time for research, design and testing in order to get things done right

  • Designer should always deliver pixel-perfect prototypes to development and never make developers guess

• Establish a scalable design process

  • The process should be flexible to support all different types of projects

  • A design process is a big time saver to set the expectations

• Hire more (great) designers

  • Find a balance among the three pillars of the product team: business, design and development

  • Design to development ratio trends

 How to switch the mindset?

• Be proactive

  • No "head-down." Always prepared to share ideas, explain the process and lead discussions.

  • Use numbers. Analytics gives a designer wings.

  • Use visuals. Leverage design skills as communication tools.

• Empathy for everyone

  • All team members are equally as important as our users

  • Speak their languages

  • A great product is created by a happy and harmonious team

• Validate assumptions

  • Ask five times "why" until reaching the factual data

  • Don't believe in empty statements and conduct a reality-check with the end users

Reflection

Enterprise UX is a complicated world with lots of challenges and constraints. However, it is also very rewarding when I untangle a complex situation, see the difference that I made for design culture and provide value to users’ lives.