User Experience Design Team / Web and Mobile Team

What is the composition of your team, and how was that composition determined?: 

Design and engineering work together on project teams. The composition varies depending on the work—sometimes it requires more developers, other times more designers. An example of a current team is: one front-end developer, project manager, business analyst, UX designer and content specialist working with three developers, two QA testers and a visual designer as needed. We’re constantly evaluating the mix of resources on projects based on changing work and discoveries. Project teams work hard to integrate new members while being able to rely on the shared knowledge and history of the core team. On our broader Web team five UX designers, six front-end developers, and five content management specialists work with a team of 40-50 back end developers, 10 project managers, 7 business analysts, and 10-15 QA resources.

Our willingness to learn from each other and fill in across roles when needed has helped us meet several challenges. One of our largest challenges creating integrated patient and member healthcare experiences is creating test data, which must be coordinated across many systems. A business analyst, UX designer or developer can assist in testing simpler stories when needed—creating test cases and executing testing. This frees QA to fully tackle the complex testing. As a relatively new, growing UX team working with an established, but growing development team, every UXer is on 2-3 projects at a time. Our adoption of lean UX and collaborative design has been critical to our success. While we grow and balance resources, we rely on our relationships with each other to keep the focus on experience.

Please describe the manner and process by which your team collaborates over a typical iteration, feature, sprint, or any other unit of work.: 

The UX Designer and business analyst do as much discovery as they can prior to the sprint, which includes interaction with the rest of the project team. As we learn about rules and systems, we share information with our team and ask them questions we need to proceed. Design sessions happen as needed—everyone is invited and participates, giving us a shared understanding of a problem, multiple solution ideas, and valuable discussions in one hour of time. Designs may or may not be done when the sprint starts—we talk as a team to decide if we can finish a story in our 2-week sprint. We use JIRA and Confluence to track stories, acceptance criteria, and requirements. Formal wireframes are becoming more rare, replaced by front-end prototypes, whiteboard sketches or designers sitting with developers as they work. 

We have daily stand ups and one hour a day is blocked on everyone's calendar. If we do not need it, everyone gets it back. If we discover something we need to sit down to talk about, we don’t need to "find a time.” Team members talk throughout the day. Conversations are started and led by anyone on the team. If an issue comes up in design, development, or testing, we know about it quickly and gather to talk it through—we decide on a direction or create new stories and continue. The team has their own project room with whiteboards where we co-locate and work. Most of the team sits here full-time, while others have guest desks to co-locate when they can.

Morale is important and tended to by everyone. We joke around, create post-it note awards, decorate desks for birthdays, keep a quote board, acknowledge and commiserate over difficulties we're encountering, and have a jar of animal crackers that is always full. As the sprint progresses, we use one of our daily meetings to look ahead at the next few sprints as a team. Balancing the mix of stories in a sprint is important for gathering test data, keeping everyone busy and not overloading anyone. It also helps us be prepared for what's coming, tackle the high-risk stories early in a release and evaluate our progress toward the next release date. Business owners and outside partners are often engaged in the sprint. BA and UX are working on the next couple of sprints while supporting the current sprint. Front-end, visual design, and UX meet once more as stories are completed, to go over and refine each page or feature. As we near the end of a sprint, the team writes the remaining unfinished stories on the whiteboard and plan out which ones we think we get done on each of the final days. This helps us swarm on the same items. The team does a demo for everyone on the last day of the sprint, as well as a retrospective on what's working, what's not and what we should do to adjust. All of our completed task post-it notes are put into a giant bucket that keeps growing. There is always a sprint-ending happy hour outside of work.

How has the fusion of design and engineering benefited your projects, products, services, and the company generally?: 

There are several topics or projects at HealthPartners that carry a reputation of impossibility. These are projects that would benefit our business and users, but are often put off due to complexity. Upgrading and redesigning our authenticated site and our plan doctor/clinic search feature were two examples. The authenticated site grew up as different applications and was often mentioned with the terms “spaghetti code” and “technical debt.” The plan search project had begun and stopped several times in the past. 

Over the last year we have completely redone both, with great success—all while transitioning to agile development and lean UX in the same time period. It’s resulted in better experiences for our users and a collective feeling that we can do much more together than anyone thought previously. We’re so proud of this and of each other. There are still several other topics that carry that same reputation of being impossible . . . several team members now comment on how they bet we can take them. It may seem like a subtle shift, but it’s made a big difference in our outlook. We don’t dread tackling those projects. We look forward to them.

Please give one or more examples of successes your team has had that wouldn’t have been possible to achieve were design and engineering not tightly coupled.: 

We are unusual in health care—we provide both care and insurance. It can be difficult from a data perspective to integrate systems from both sides, but it's an incredible advantage for our users who are both members and patients. We recently launched a new authenticated site, where we tried to tie together all claims and patient information for a care event—say a doctor visit. Health care claims are complex and they come one at a time. As a team, we had to find a way to tie claims together when a visit produced multiple claims. We had some added difficulties: we had three months, no prior claims documentation, no official claims business owner to serve as a SME, and our team was using a patient API for the first time. With such complexity, we would never have been able to accomplish this task working in silos.

We met with teams who grouped claims using other databases and evaluated whether or not we could use those (we could not). We learned as much as we could and then built our own proof of concept grouper. When the claims came through, we realized it was not working as needed. A certain type of claim did not include essential data needed for our grouper—and that type of claim was much more common that we had anticipated. We had only about a sprint and a half of development time left so we met as a team and talked through the issue. It wasn’t acceptable to launch this grouper—the experience would suffer too much. We evaluated remaining stories and de-scoped what we could. We opted for simpler solutions in other cases. We redistributed testing tasks to non-QA team members where there was low risk so our QA resources could fully test the second version of our grouper. The end result was a successful course change we all agreed we'd rather not have had to do—but were very proud we could do it. The experience launched, with a lot of positive reaction, because we were able to work together as a team.