Natalie Hanson Stretching the Definition
Stretching the Definition of DesignOps with Product Development
Chris Moses, Director of Product Management, athenahealth
From the Design Operations Summit website:
When is DesignOps about more than building tools and systems that improve the effectiveness of R&D? For athenahealth, our DesignOps team has housed two cross-product teams—by organizational necessity at first—that have become critical early adopters of the instruments and programs their DesignOps colleagues have developed.
He’s feeling a little bit of imposter syndrome; he joined their Design Ops team (as a member of the leadership team) six months after it was formed. Prior to that he was in product management.
They started as a clinic, and software was an enabler. They joke that they are the least bad option of bad software in healthcare. Their software helps doctors treat patients and help doctors get paid. There are a lot of federally mandated checkboxes that don’t help with usability issues, either. But, they have had a lot of great success due to federal incentives for EHR software. Now, there is more focus on end-users, and it’s a replacement market, which means there is a lot more interest in design and usability. How to deal with the mountain of design debt?
They had been working in waterfall when the federal incentives stopped, and they made the transition to agile to be more responsive to market needs. At the time, the UX team was about 85 people. They had deep specialties, but they needed generalists in each agile team. The charter of Design Ops was to take as much friction as possible away from those embedded designers.
The identified some quick wins based on challenges the organization as a whole was facing, but they didn’t necessarily have as much of an impact as they would have liked. They decided to focus on user attrition. Where to start dealing with this mountain of design debt? How to quantify paying that down, and convincing your leadership to invest?
They worked to identify mission-critical workflows; they identified 55, but there were closer to 100 in total. They did that through two-week “audit” sprints:
In order to hit all 55 workflows, they had to pull in their extended team (including engineers). They created a measurement called ‘Design Quality’ using Jakob Neilsen’s heuristics. Each workflow received a quality score, and the outcome of an individual workflow looked like this:
And here is the summary view:
The goal would be do have everything all the way to the right.
There were 3250 findings across those 55 workflows. Their approach helped to create shared language and give a measurement framework. It has also enabled them to make targeted design improvements, and created a sense of shared ownership across the team.
Now they are working to scale this method. They want it to take less time, for people to be able to do it asychronously. So now people watch a video, document their findings, and their team aggregates them into a dashboard. They are seeing that more and more workflows are being measured as they are being released.
They were having some growing pains with these new methods, and there was also the backdrop of new EHR certifications for the organization as a whole. As they collect a body of data, they have work to do to decide what a “good” score looks like, and how to encourage the right focus (e.g. not the number, but improvement over time).
There is also work to do to help teams leverage the Design Quality score. Teams are still siloed, though better organized due to Agile. They are not yet sure what the ceiling will be. Why should Design Ops manage this, rather than Product Managers? Their customers are Senior Product Leaders, Product Owners.
They now have a framework for the services they offer throughout the SDLC:
And they still have questions that many of us have. What do we know about X? What are we doing about X? They have a graveyard of knowledge management systems they’ve tried to address these issues. Historically, they used org structure as a proxy for organizing data, but because they re-organize frequently, this has been problematic for storing and retrieving knowledge.
Lou Rosenfeld shared with him the idea of Pace Layering from the creator of the Whole Earth Catalog:
Faster layers outside, slower change inside. How do we operate closer to the nature layer? They need to bring a new, more stable taxonomy to how their information is organized. They used the Jobs To Be Done approach to create a job map across the company, and it took off like wildfire. It gave them shared language, and it was more robust (slower to change) than other ways of thinking about their work.
You think that if you just get the right team configuration, you’ll solve these problems – but new team structures inevitably create new challenges. So, instead they are stretching the definition of design operations. They have one team that has become a model citizen, but they still have many more questions. What should be their role in visionary redesign? Should they spend more time communicating across teams? Hopefully we can find some answers together this week.
Natalie Hanson 
Pingback: Design Ops 2018 – Recap | Natalie Hanson