Design Sprint
Using design thinking to align and collaborate across multiple disciplines
My role: visual designer, prototyper
The IBM Watson Tooling team converged in Littleton, Massachusetts to hold their very first Design Sprint. The team was comprised of offering managers, developers, executives, and designers. We applied user-centered design thinking to align and structure our week.
The Challenge
The short-term tactical goal for the next three months was to extend the current capabilities of the Watson Experience Manager, the tool used to customize and support Watson applications. There were multiple personas built to support the product, but since the Design Sprint was condensed and accelerated, we decided to focus on our primary user, Katherine.
Her role is to gather representative end user questions, find relevant content that answers those questions, and create ground truth by mapping questions and answers. She's an expert in her domain. When she doesn't know the correct answer, she knows where to look or who to ask. She has basic computer skills and doesn't know what machine learning is. (User research compiled by Ricardo and Aaron).
The purpose of the Design Sprint was to have a prototypes that focused on four key areas of tooling that Katherine struggled with:
Question ClusteringUser scenario: Kathryn has a set of questions but doesn’t know how to organize them. Pain point: It's cumbersome to cluster and organize questions.
Content IngestionUser scenario: Kathryn would upload content and suggestions would be given before files were actually ingested. Pain point: The tool rejects her content but doesn't give any feedback as to why and doesn’t correctly segment the content.
Question and Answer MappingUser scenario: Kathryn teaches Watson by mapping questions to answers. Pain point: She's unable to map multiple answers or find answers to questions in the tool.
PerformanceUser scenario: Kathryn wants feedback on her activity and actionable insights. Pain point: There’s too much data to parse and she doesn’t know what steps to take next.
Understand
Each day started with people volunteering to give a 5 minute lightning talk on a critical topic that would influence the tooling in some way. There were a wide range of topics covered, from error handling and implications of clustering to tooling for hybrid environments. I shared a lightening talk on design inspiration and how we could delight the user.
The first step of the design sprint was to understand and to level-set the team. We did this by evaluating the synthesized research that had been completed to-date and review the journey map of the as-is scenario. This helped to align the team on the major pain points we were trying to solve.
A single UI framework was created for each team to use. This allowed them to focus on the unique challenges of their tool without needing to exert unnecessary time and attention on the surrounding container. This also gave a more consistent look and feel when each team presented their prototype during the final Playback.
Once everyone was level-set and we understood what the major pain points were, the next step was creating the to-be experience. We divided into teams that included one prototyper, engineer, designer and offering manager. Each team would focus on one area of the tool. I was on the Performance team along with Gavin (Offering Manager) and Bill (Software Engineer). Using design thinking techniques, we brainstormed the ideal experience for our users and created a to-be scenario. We then played back our findings to the overall group.
Diverge
The next stage of the design sprint was to diverge. We did this by sketching 5 ideas in 10 minutes, then 1 idea in 5 minutes, then 2 storyboards in 15 minutes. Getting all your ideas out on paper, regardless if they're good or bad, can generate huge breakthroughs by forcing people to let go of inhibitions.
We played back to our team, used zen voting to garner consensus, then remixed our story board to eventually converge on the best ideas.
Prototype and validate
Prototyping and validating was the third stage of the design sprint. Armed with our new to-be scenario, we began to prototype the user flow with paper. We determined what the user story was going to be and what assumptions we needed to test. Testing with other members of the team allowed us to refine our prototype before testing on proxy users. No matter how big or small, testing can surface invaluable insights that wouldn’t have been uncovered otherwise.
By the second day, I began coding an interactive prototype that incorporated the useful feedback we’d received from our testing sessions. For the next 2 days, we continued to flush out the user interactions, test on proxy users and played back to the broader team.
The Outcome
On the fourth and final day, we held our final playback and shared our end-to-end prototypes with our key stakeholders and the rest of Watson. The 3 1/2 day design sprint encouraged team collaboration and allowed us to quickly iterate, design, prototype and test our assumptions. The insights gained would immediately impact the product development of the Watson Experience Manager for the next quarter and influence the long-term strategic vision.