Design at Scale 2021-How to Drive a Design Project When You Don’t Have a Design Team (Davis Neable and Guy Segal)

—> Hi everyone, we are from Manulife, and we are here to share a case study about a major design project that had no dedicated design team

 

—> Our story had a happy-ending, and we learned quite a bit, despite a bumpy road

 

—> We will share what worked for us, what didn’t work, and what we wished we could have done
  • We hope you can use this
—> Before going into the details of  the project, let’s set up context
  • We work at Manulife, a financial company headquartered in Canada, with 37,000 employees worldwide
—> For specific project, we are focusing on the Canadian segment of the company, which serves 4 million people

 

—> Both of us are directors at Manulife Canada, but when we worked on this, Davis led the team on mobile experiences, and Guy lead  the team on web experiences
  • Teams were located in different parts of the organization
—> Guy will talk about the project itself and what worked in completing it, while Davis will talk  on what didn’t work and what we wanted to try

 

—> So what was the project?

 

—> Simple brief: Design a single sign on  for all business units in Manulife Canada
  • This project would get rid of unique way of signing people in and bring in one doorway to rule them all

 

—> There were known existing contraints before they event started
  • Project was led by technology, and technology catalyst was the overhaul of the backend authentication system
  • Each business unit had dedicated designers working on their project, but there was no work done across business units.
  • Projects and units were siloed and people weren’t encouraged to think beyond their unit
—> No design team existed for the overarching experience for the whole company
  • So how do we drive the project?

 

—> A question though: But what’s so difficult about designing a log-in?
  • Easy way for people to sign in and sign up, and navigate through a site. What’s so hard about it?
—> The challenge was that leadership underestimated the problem, needed to accommodate everyone’s needs in the organization, and required consensus from four units, and required each one to feel included
  • Prior authentication projects, resulted in fragmented authentication portals for each business unit

 

—>The  problem was not the technical problem of creating experience of sign in, but rather getting understanding across business units

 

—> It was a complex problem was not solution based, but dealt with cultural team alignment

 

—> So we tried different things. Some worked, some didn’t, some things we came up with  afterwards

 

—> Here were the plays that worked

 

—> First, created experience vision to align everyone
  • Tool that provided a tangible goal for people to work towards
  • Focused everyone on what experience would look like for users
    • Experience vision was technology agnostic
    • Aligned groups with unified way, and a visible target the teams could aspire to

 

—> Here’s an example from an experience document, which demonstates experience and ease of use for the user

 

—> More detailed example of screen flow that provided a clear vision for the people involved

 

—> This document worked well to give stakeholders an understanding of how the sign in solution would be used, and showed the value for the users

 

—> We also included definition of design principles to help stakeholders make decisions
  • Example of consistency across all business unit efficiency to unify business functions
  • Principle of making it personal to help people focus on what the end user experienced

 

—> Another approach was forming a core task force to cover tasks that impacted every user
  • It was a small team of core capabilities and knowledge
  • Representatives from business, tech, design, helped us move fast and review many iteration per week

 

—> The team was empowered to make decisions, and didn’t have to wait for formal feedback cycles
  • Since there was an overall experience vision, stakeholders could picture what was being worked on, so they didn’t see need to be involved every step of way

 

—> However, there were limits to what the macro team could do
  • So we leveraged designers in business units to dedicate time to project
  • Built an ad-hoc design team of different designers to create a large design team that was used when needed

 

—> There was also rapid iteration through testing cycles
  • Tested modules in the framework with moderated/unmoderated usability testing
  • Tested terminology through tree tests
  • We had multiple rounds of usability tests to minize errors

 

—> However the work that we all do, is fundamentally human, and humans are messy, with things that didn’t work

 

—> Here are the plays that didn’t go as expected

 

—> We formed an additional support team that was leveraged as needed, and chose key designers across impacted business units, and asked them to participate

 

—> Felt if  designers given small project to work on, we could get things done quicker

 

—> However the flaw to this plan, was that  the role of trust was underestimated
  • Design is often asking yourself to be vulnerable, asking people to critique work, and trusting directions given to you as the right one
—> Individuals tapped to be part of ad-hoc team were part of Guy’s organization, and Davis didn’t have a relationship with them
  • People were reluctant to work under Davis
  • Davis didn’t pay attention to hesitancy, and didn’t see lack of trust
—> She wished she spent time cultivating relationship with the group as a design leader and designer

 

—> Since designers were embedded in business units, the units determined their roadmap direction.
  • Getting business units aligned and understanding the impact of project to them came later
  • Business units were reluctant to give designers to the project
    • The result was that there were conflicting directions from business unit leadership and design leadership to the designers
—> Wish she could cultivate trust and a team environment

 

—> Content Management Strategy Management didn’t work as well as desired

 

—> We had a talented content strategist who owned all copy for the initiative and laying out content strategy and micro-copy throughout the experience, both desktop and mobile

 

—> Thought that were would be a consistent content experience throughout
  • Single set of content strategy for the project
—> But a company reorg happened and the content strategist was shuffled off the project
  • Now we had to scramble to grab pieces for all work that was built out by the strategist
—> Were happy to outsource work to the strategist, but there was a single point of failure, and things really went awry

 

—> Valuable to invest time upfront to make sure work done was highly visible and more folks assigned to content piece, and had design leadership and designers
  • Needed to have multiple content strategists working with the  lead content strategist

 

—> A few plays we should have run in hindsight’s, as retrospective and reflections are key part of moving forward

 

—> Paused and thought of what we could have done differently and want to take these learnings going forward

 

—> Here were our top three wishes:
  • Doing a formal kick-off: There were many moving parts on project, as it started as a technical engineering project that evolved into single sign-on role. For each iteration of the solution and problem being solved, more stakeholders and perspectives were brought on boardExpectations kept changing. There was no official kick off held, and no points were given to formally orient the stakeholders to what was going on
    • At no point is it too late to have a formal kick off session. Needed to introduce key stakeholders, know their roles and responsibilities, make sure the team understood those as well, and the direction of the project itself
    • Great design comes from great understanding of problem to be solved. Without that, we are left scrambling to band-aid a solution over a series of assumptions
    • Kickoffs provide a sanity check

 

  • Second was drawing from a service blue-print, from the designer tool belt
    • Service blueprint tool
    • We had done journey maps and experience vision maps, along with flows of wireframes, but service blueprint would have included swim-lanes for systems involved with the overall system
    • Included supporting technology, back-end systems, users involved, etc.
    • Blueprint would have clearly articulated all of what was involved with the solution to the project stakeholders
    • A simple UI often requires a sophisticated back-end. Having a service blue print would have helped business units understand impact of experience would be to them
Finally, we wanted a more collaborative development, design process to happen sooner.
  • The project difficulties weren’t about the artifact built, but rather the cultural tensions
  • The work done is nothing, unless you have strong team based on trust and collaboration. As leaders in our projects (and we are all leaders), we need to think how we are fostering team motivation and collaboration from the beginning.
  • Easy to cut opportunities for collaboration, as it feels it might take longer. I’ve yet to see opportunity, where investment in relationships has not paid off, and you will be stronger for it
  • User Experience will be better for it as well

—> As Guy mentioned, we were proud of the project and experience that wa put-out, and we will continue to roll out the project

 

—> For any project you are on, take a look through the lessons learned to see how they apply to your journey
  • Take the time to invest time in each other, relationship, and collaboration
—> We are providing experiences for fellow humans, so let’s provide those experiences in the context of the work we are doing as well

 

 

Q&A

  1. Could you talk more about the simplicity over business unit efficiency? That sounds like a huge challenge.
—> Go back to first principles for design.
  • Approached principles thinking of tough choices, designers would have to make

 

—> This was a big challenge, since organization has behaved and worked in certain way, and each business unit functioning as it’s own company

 

—> Having had projects in past that didn’t work so well, we had a motivation to try things differently

 

2. How small was the core team? and how did you get that “awesome power”?
—> Core team was myself and Guy, where we worked on different parts of the experience together
  • Guy on tactical execution of design and design team
  • Davis would work with stakeholders and broader strategy level
—> From design perspective we had visual and product designers working together to align the look and feel across the business units, to provide a consistent feel for Manulife

 

3. Was this process initiated during COVID or before? And were the trust issues exacerbated by the team not being together?
—> Initial project began in end of 2019, and project was initiated before that

 

—> Trust issues were not exacerbated by shift to remote work, and were there beforehand

 

—> Being intentional about building trust can work even when everyone is remote