INTRODUCTION
What do you do when your current technology investment suffers from a high degree of entropy which, causes poor performance, limits scalability, and makes delivering new features expensive and risky?
The answer might seem simple at first…break the current solution down and rebuild, right? With the massive time and budget investment already made from both the company and its widespread user base (70% of the use market), delivering a new solution was something that needed to be handled with great intention and care.
With the initial scope of the project being as broad as the problems we could potentially solve for, we first had to identify an initial path forward.
GUIDING PRINCIPLES
It’s not about delivering a single replacement solution to what’s existing but, instead, designing a platform of modular, reconfigurable technology components.
The attempt to be all things to all users in a single product is what got the company into this problem in the first place. This was an opportunity to take a different approach. What that initial approach would be was still fuzzy but, we knew we had a few mandatory characteristics that any potential component within this new platform would need to possess.
THE TEAM
I led the design strategy, research, and covered the cross-disciplinary project management.
Considering this was a seriously complex project, I was not in this alone. My village consisted of a Chief Product Owner, a US Product Owner, a Global Product Owner, a Solutions Architect, a Chief Technology Owner, a Marketing Manager, access to a handful of other designers from other disciplines (visual, interaction, IA), and over 30 SMEs located in various countries around the world. Sound daunting? Not for a professional cat herder!
Actual image of me herding cats
THE PROCESS
Part 1: Understanding the problem space
Successful design projects not only meet the needs of their user, they also maintain an appropriate balance of managing business goals.
METHODS
Secondary research: My first step in this project was digging through our internal materials to see what I could glean from existing data on the project background, the constraints, and the problem space.
Stakeholder interviews: Once I had gathered enough information to start forming additional questions, I set up sessions with each of my project stakeholders to get their take on the project evolution and identify their individual goals.
Product strategy workshop: Now that I understood the individual perspectives of my stakeholders, it was time to start building a collective vision and strategy for the platform as a whole.
Part 2: Identifying opportunities within the larger ecosystem
After a series of stakeholder workshops, I was left with seemingly disparate data points across a vast landscape and needed a way to make sense of how any initial component would fit into the larger scope of the platform.
METHOD
Ecosystem mapping: I started creating an ecosystem map to help me structure the data, visualize the relationship between the people, places, tools, information, and pain points within that ecosystem, and illuminate the highest points of friction.
Part 3: Picking a place to start
There were various points of interest that we could have explored but we wanted to start someplace digestible. The goal was to identify a component that was quickly achievable yet impactful to our users. It had to qualify as something that could be as unobtrusively deployable as possible while still meeting the criteria for platform development we had defined at the start of the project.
This was a tall order but we finally landed on content. The secret sauce of the existing solution is our proprietary content and we have teams of folks all over the world working to create and deploy that content to our end users today through legacy tools and isolated workflows. It isn’t sexy but it’s fundamentally important to customer satisfaction, retention, and our long-term value proposition.
So, the initial design challenge then became creating a new, systemized way of developing and delivering content to our users globally while also giving them the ability to further customize that content for their particular use case.
The potential impact of this solution (if we got it right) meant increased efficiencies across internal teams, increased value for our consumer, and the potential to increase revenue by discovering new ways to deliver more relevant content at the point of need.
Part 4: Defining the users
At this point, we knew our broader set of users at the platform-level but now, it was time to take a deeper dive on developing the personas we were designing this component for.
Persona development: I used the information collected from my preliminary research, our initial workshops, and stakeholder interviews to start building out a first draft of our personas (both internal and external) that I could later validate post user research.
Part 5: Mapping the journey
Initial personas in hand, it was time to start conceptualizing their journey.
METHOD
Journey mapping: We gathered a smaller group of stakeholders more relevant to this particular component to help us construct a journey map of the existing user experience. Due to time and budget constraints, we focused on our internal content creators and developers located here in the US to start. The final framework allowed us to align our stakeholders on key user interactions, pain points, and needs to illustrate areas to elaborate with user research.
Those areas included the disconnect between content creators and developers, the redundancy of tools to get the job done at a global scale, and the lack of insight around how end-users consume that content.
Part 6: contextual inquiry & user interviews
METHODS
With stakeholder alignment on our areas of focus for this initial phase of user testing, I designed a mixed methodology research plan aimed at validating the assumptions that had been made during the journey mapping exercise and addressing any existing gaps.
Contextual inquiry & user interviews: I asked users across the content creation and development process to join us for part discussion and part observation with the goal of better understanding their activities, process, tools, and how they interact with other teams.
SYNTHESIS & FINDINGS
In total, I gathered over 340 data points across 18 sessions. Here’s a quick rundown of how I translated all of that information into something actionable:
Data entry/coding: Translated the data into a shareable/manipulatable format and prepped for analysis by categorizing individual data points (keyword, journey step, positive vs negative, etc.).
Data analysis: Grouped data points by theme and formulated key insights or takeaways based on the data that was most relevant, frequent, surprising, or powerful.
Opportunity definition: Expounded on the meaning of the data point themes identified by translating them into opportunity areas.
Opportunity prioritization: Further categorized opportunity areas by theme and identified the areas that would have the largest impact.
RECOMMENDATIONS
At the end of the synthesis process, I arrived at 4 key opportunity themes across the content creation and deployment journey. Those themes were usability, visual design, collaboration, and efficiency. My recommended focus was around efficiency.
Part 7: Concept sketching
At first, the amount of places to start sketching ideas for addressing challenges around efficiency were overwhelming. In order to start putting pen to paper, I needed to distill it down to something I could get my arms around. I went back to all of the individual insights uncovered in synthesis that related to efficiency. From there, I reframed those insights into “how might we” statements and reorganized those into affinity groups.
From there, I had 3 more manageable sub-categories which, included efficiency of workflow, external user customization, and global capabilities. I took some thought starters around the efficiency theme derived from our initial user research and moved those that had the greatest potential for hitting all three of our sub-categories into sketching. In the end, I had over 20 sketches for the team.
Part 8: Defining the requirements
It was finally time for our platform vision, user requirements, and component strategy to all come together into a cohesive design but before we started building, we needed a solid blueprint.
METHODS
User-flow diagramming: In order to arrive at a globally unified interface and interaction components, we first needed to visualize the existing user flows across content teams to help us determine how that singular approach should come together.
User and technical requirements definition: We worked closely with our PO and technical leads to establish an MVP feature list to help ground the the team as we prepared for architecting the front-end experience.
Participatory design workshop: Then we brought together a diverse group of stakeholders, designers, and SMEs for a workshop to map my initial sketches to that meta-user flow, determine technical feasibility, and measure against our defined requirements.
Collectively we were able to prioritize sketches for our prototype.
Part 9: Design sprints
With how much time had already been invested in getting the project to this point, we knew we wanted to move as quickly as possible to something tangible so we gathered a team and dedicated 5 weeks of project time to design sprints.
METHOD
Design sprints: Our design sprint team included myself as the lead researcher, a prototyper, and our product owners. The 5 weeks of sprints included a dedicated week of prototype build out followed by 4 rounds of testing and iteration. At the beginning of each new sprint week we shared our progress, the feedback from that week’s testing, and our recommended next steps with our key stakeholders to encourage participation and maintain alignment.
One-click test: The strategy I arrived at for round 1 of testing was to validate that our key UI tasks determined in our participatory design workshop were easily achievable within that first build. This also helped us focus the interaction design to something narrow enough to deliver in a week’s time. We accomplished the results we were looking for by architecting a screen around each of those key tasks and deploying a one-click test through a hyperlink to a wide group of participants.
Usability testing: From there, I suggested we utilize each subsequent week as an opportunity to explore each key UI task as a theme and take a deeper look into the usability of the associated interface. In total, we remotely conducted 10 usability sessions by the end of week 5.