Royal Bank of Canada
Noticing that business requirements were unclear and lacked context, developing the right features was difficult.
To fix this, I worked on making the requirements clearer and more detailed, ensuring we could create successful features that meet RBC’s goals.
Observe
After taking part in many initial meetings that were meant to be sessions to iron out requirements from business, I have observed that the conversation was skewed towards technical needs. In short, most of the design stakeholders were quiet, and no conversations were happening that revolve around goals. These meetings consisted of looking at an excel spreadsheet of requirements and discussing what is needed to build it. As a result, outputs were being determined based on technical direction, with no context as to how users will make sense of what we intend to build for them.
Understand
Reading a spreadsheet of requirements line by line, did not help to describe what the business has in mind to build, let alone why it needs to be built. Since these requirement gatherings were attended by stakeholders from different fields, it is better to express requirements as a story map, for a better understanding of what the business intends not just in terms of what needed to be developed, but it needed to be within the context of how the user will use it.
Convert Requirements To Story Maps.
Rather than getting lost in what features should be determined to be built, framing it in a way that keeps users and what they will be doing with the product keeps them front and center. This allowed conversations to be more natural and understandable especially when dealing with multiple stakeholders, rather than get caught up on technical jargon. For this, I utilized used story maps to help myself and my team understand with greater context and clarity the activities, tasks, and stories we have to produce to achieve business outcomes.
Story map outcomes
Subject matter is understood not just by business and technology stakeholders.
Contextualized business and technical conversations within the framework of user activities, and tasks.
Some semblance of content structure starts to emerge, which can be a good starting point to begin work in information architecture.
Small stickies forces participants to be brief and concise in their descriptions.
Journey’s in the product become clearer and more identifiable in groups, making it more versatile for planning.
Collaborate
Contributed and participated in design sprint workshops to identify business outcomes, user needs, and technical feasibility. Since these design sprints are meant to acquire details in a short amount of time for outcomes desired in the product, I needed to make sure that certain workshop tasks where in place, so as to capture the goals that are needed to tailor interaction designs to.
Proto Personas
To manage fluctuating requirements, expectations, feature creep, and lack of initial research, I advocated and pushed for the generation of Proto personas. This helps to focus and align designs, rather than designing for a grocery list of assumptions which feed the “we should design for everybody” mentality. The more assumptions we have, the greater the risks are in creating a lot of stuff that may not be valuable to users. Not only does Proto personas help in scoping expectations, it also reduces wasted work which is costly.
Proto persona outcomes
Each design is focused based on Proto Personas.
Alignment on who we are assuming we are designing for.
Features and feedback are managed and considered based on how well they address the Persona.
Communicated the product to external teams through a more naturalized approach using the perspective of the Personas
We have a good picture of who we want to talk to, and test designs through.
Feature creep is managed.
There were certain occasions when I needed to visualize the relationships between different interactions between, people, processes, and systems that are directly tied to a service. For this I used a Service Blueprint.
Service Blueprint
Here we see the interaction touch points, and support processes of a back-office staff, for processing issues submitted by customers for support.
Service blue print outcomes
Internal interactions within the service is visualized.
Clarity in every phase of the journey is detailed along with supporting elements that make it happen.
Instead of talking about the details of the service, we now have a visualized artifact of the service.
Better position to identify areas to improve within the service.
Future State Journey Map
Although Service Blue prints assisted in visualizing how user journeys relate to system processes in the background and their visible interactions with it, I needed a simplified version that filtered it down to only the phases (steps) a user goes through to complete a goal in the system, and the actions involved in each step. Although we have not interviewed users to capture their thoughts and emotions in their experience, we at least captured what we assumed to be actions they take in their journey.
A lite version of the Future State Journey Map.
Journey Map Outcomes
Facilitates conversation and an aligned view for the team.
Communicates understanding of the user or service to the team.
Information is memorable, concise, and creates a shared understanding of the initiative.
Allows team to focus and isolate areas that need improvement or clarity.
With the team’s collaboration in understanding the service and initiative we are planning to design for, I was better informed in crafting designs based on information provided by Proto Personas, Story Maps, Service Blueprints, and Future State Journey Maps.
Design
To communicate clarity in design intent, I used wireflows to describe relationships between pages, as well as system interactions with the user.
Wireflows
Wireflow Outcomes
Clarity in design intent.
Documentation of detailed behaviors of the design.
Blockers for developers and other stakeholders who depend on design deliverables are minimized.
Better alternative to user flows which communicates context by way of what the user sees.
For validating the effectiveness of the designs, I assisted researchers in testing the product by providing them with prototypes and assets to show in front of research participants.
Testing
The more closer a prototype resembles real world scenarios, the more effective it is in gaging user attitudes, and behavior. With FIGMA, I am able to add detailed interactions of the designs to mimic live products.
Prototyping
Testing Outcomes
Prototype reflects realtime click troughs to mimc real user interactions in the real world.
Insights into how predictable the app is on certain tasks.
Domain knowledge is measured in terms of how users comprehend the content in the site.
Insights into the users attitude about the site.
Understanding of the site’s fittingness towards the user’s mental model in terms of their goals.
Measurements of how well users performed tasks in the site.