Healthentic development worked in a three week, Agile/Scrum sprint cycle. To successfully mix user experience design with existing engineering practices, I established processes and tools light on documentation and heavy on working prototypes and reusable design assets.

Process. Captured moments in the design process, from ideas to research, creation, refinement and development.

Highlights

Though the process was fluid and flexible, I generally approached projects within this framework.

  • Understood the business context, goals, key requirements.
  • Facilitated discussions and communication around key scenarios and design approaches.
  • Interviewed stakeholders and customers about the problem or project.
  • Defined research-based user scenarios and tasks.
  • Created and collaborated on creative brief (project objective, key scenarios, primary persona, design principles).
  • Facilitated design jam or design studio as needed (engaged subject matter experts, developers, customers, executives).
  • Iterated.
  • Conducted user testing.
  • Iterated again :)
  • Reviewed close-to-final requirements with team.
  • Created and maintained documentation.

My Role

At Healthentic, I had the awesome opportunity to work on product and design strategy, be immersed in an Agile/Scrum development cycle, serve as product owner, build lots of prototypes, interview customers, conduct usability testing, and manage the UX process along side a very smart, talented team. I led much of the UX projects for the Population Health Dashboard product and surrounding product and design efforts.

Problem

Anyone who has done user experience work in an Agile/Scrum environment knows how difficult it can be to size, scope, and fit design work and deliverables into a precise cycle. The paradox is that user-centered design is iterative. I’ve found that the challenge is getting to the big picture through the short incremental cycles of the development process.

How do we really focus on experience? This challenge is pervasive and it was a part of the challenge at Healthentic too. To boot, Healthentic built health informatics products aimed at non-technical people. This meant getting to viability and feasibility—let alone everything we wanted focus on—wasn’t always easy. Three tactics that were effective for the Healthentic team was to get ahead, test early and often, and go light on documentation.

Process

I followed a rigorous process, but there were often new problems that required new approaches. With such a wide variety of tools in the UX toolbox I always tried to use the best tool possible for the job at hand. I established a general approach that we followed which started with getting at least two sprints ahead of the development team, if not more.

Getting Ahead

Getting ahead meant I had to have a good view into the product roadmap and strategy. I participated with the other designers and product managers in reviewing the road map and developing a high-level game plan to deliver on business priorities. We would start by building a work plan for each project or milestone. This gave the team the ability to take a guess at the project and design approach.

Story Breakdown. This document was used to capture a high level description and acceptance criteria for a project. The product, engineering, and design teams worked together to construct an outline of the work required to complete the project. This was tremendously helpful as an input for the product road map and work estimation.

Often, at this stage I would write some out some of the key user scenarios and do some sketches to think through the design problem as a team. We would start working on this early to inform the ever-evolving road map.

Test Early and Often

Feasibility was almost always a big question that needed to be evaluated. Our goal was to create the ideal user experience, and this had to be done within the constraints of the messy heath claims data our product used.

Sketch and Notes. This was a sketch I did with one of our clinical researchers as we worked through the details of a new report on maternity and motherhood for the Population Health Dashboard. Health data is messy, so spending time with subject matter experts was an essential part of turning complex data into something a non-technical user could use and understand.

To address this, I engaged our clinical team in prototyping exercises and design activities early so we could work a problem together. This would help us rapidly arrive at something feasible and reasonable given the challenges.

Using what we learned about the feasibility, we would quickly put together an artifact to evaluate with customers. I made good relationships with our account management team to quickly connect with customers to do a test or walk through of a user scenario and prototype. Early testing provided tremendous value and yielded actionable outcomes quickly.

Prototype Test. An Illustrator mock up I created to test with a customer. We used ‘think-aloud protocol’ to understand how a customer would enter information about health events into this dialog.

Light Weight Documentation

Light weight documentation was my response to the timing and fluidity of ever-evolving requirements, designs, and data constraints. When I started at Healthentic, the expectation was on detailed functional and product specification documents. But these were difficult to use given the development cycle.

Prototype and Documentation. I created a fully functioning prototype of a “wellness plan builder” feature for health benefit managers. Because our developers could see and touch the actual content and functionality, our documentation could be abbreviated. I documented the user task flows and included user scenarios and business objectives along with the prototype.

I implemented a process that enabled us to work and communicate around highly-functional prototypes. The process didn’t change much—start with lo-fidelity mockups or sketches—but where we ended up did change. Instead of delivering excruciatingly detailed documents, I would deliver functional, clickable prototypes in code. What couldn’t be communicated by the artifact itself was written up in a requirement and the entire package was versioned.

Of course, it is always a work in progress and there were plenty of occasions we just couldn’t help but create more detailed documents. The important thing was that I spent less time documenting and more time designing and communicating with the team. This approach worked well for the Healthentic team and processes.

Outcomes

Our design and product management processes had tremendous success. Stakeholders, developers, and executives enjoyed being a part of the process early on; our off-shore team benefited from our functional prototypes which reduced churn. All in all, we were able to successfully release major updates quarterly with smaller enhancements throughout the cycle.