Product Portfolios, DesignOps and Design Systems

Inside the #1 rated American academic medical center is The Center for Digital Health is only 3 years old. I came into the organization when only 1 other Lead/Director was there before me.

I was in charge of a portfolio, then DesignOps and the first ever Design System and teams.

WHAT PROBLEM DID MY TEAM SOLVE FOR OUR USERS?

---

Solving for the internal providers and clinicians and for that user set to get the information they need as fast as possible.

I came in fairly early on and when portfolios, teams and how UX might work inside those teams were still being structured. The KMD was essentially Knowledge Management. It catered to providers, nurses and clinicians. It was the essence of what they know and could look up almost any medical topic to refresh themselves.

The team worked on several internal knowledge-based products and the beginning of a new one that has now gained quite a bit of hoopla that sits in an iFrame inside the Epic’s EMR (electronic medical records) system.

• The new product helps clinicians diagnose and see how they might help someone with particular conditions. We started with 4.
• Quite a bit of user research had been done before I came onto the project.

How we solved for our providers

Assumptions

• Initially our Medical Director had assumed the product would be for specialists for each condition we had
• We went through user acceptance testing and realized the product needed to pivot. The audience is sometimes different than you expect, even if you have medical professionals helping you figure that out.
• After User Acceptance testing, it became obvious the specialists were offended by the tool, they said they were the experts in that condition and therefore they didn't need a tool to help.
• However, Family Medicine professionals loved the tool. It helped them with conditions they wouldn't normally run across as often. At the very least it would help them find a specialist they could send the patient to.

Sometimes the best UX stories are knowing when you should pass something on rather than try and become all knowing about a subject someone else already spent 10 years learning about. I had been using another Lead/Director as a SME and we decided it was best he took that pillar of products on as the Epic EMR was his speciality, and this product would be an iFrame sitting inside EPIC.

ONWARD TO DESIGN OPS

---

I had just spent time creating 4 video courses for LinkedIn Learning on DesignOps. So when I went from a contractor to full-time it was for a DesignOps position.

If you don’t know anything about DesignOps it is about processes, methods and craft with translates to people, Governance, tools and workflows. It is all the things those of us who have been in UX as long as I have do as Managers and Directors for our teams. All the things you need to grow the teams, hire, educate, create processes and flows for how we work with others, the governance, defining what success means, and managing all the tools. Having someone with the title takes all the drudgery away and lets people be more effective at doing what we do best. Helping our uses.

While we had a pretty long list of things my boss and I wanted to work on, here is part of what I did.

• A skills assessment for design, UX and user research
• Ways of Working presentation and monthly quarterly report webinars
• Moved team files from Teams to Sharepoint so there was a central repository
• Created home page for XD and additional folder structure (e.g. portfolios)
• Consistent set of design tools
• Figma purchase & administration
• Supernova purchase & administration for the Design System
• Retired InVision and Sketch
• Education recommendations on home page
• XD in global intake / Aha usage
• Workspaces - Three Shields, DesignOps, Design System
• New hire onboarding guide
• Baseball Cards for people to get to know their fellow UX’ers
• Workflow for how to hire
• Identified a Mac purchasing process
• Show & Share (a weekly meeting for designers to share work)
• Creating a new set of personas. 3 tier levels so you truly understand for whom you are building for, and helps to identify who those users are
• Training for how to use Figma for new designers

• "How we work" flows and graphics and defining exactly how we should work with others which also led to working with Slalom on a Playbook for the CDH. I did a series of stakeholder inteviews and came out with some facinating thoughts and the fact even Product didn't think they were far enough in front with Business on strategy

I then helped Slolam with how we might get buy-in with all the teams on working better together, communication and the surveys we would use for all the organization.

THE FIRST DESIGN SYSTEM FOR THIS COMPANY

---

The problem to be solved

The main problem was a typical problem and why people create design systems to begin with; Consistency. There were 57 examples of a button and they didn't look at all alike. Initially we had some stakeholders who didn't understand, but

We originally had a dedicated XD lead to run the first ever design system. I inherited it just after a few months after the Lead/Director decided to move on to another project.

How it was solved

Luckily I had put together a design system at H&R Block as well as being on the [super early] version of Watson Health’s version of Carbon.

While the vendor had many, many, people working on all aspects of what you need to put a design system together, we had 4 designers and 4 front-end devs. We split up the work and the vendor did 10 components and we ended up doing 12 before v1 release.

Working toward version 1.0

I concentrated on managing my team and managing the vendor.

• We worked hard on creating our own goverance flows
• The vendor, myself and the lead for our front-end created several development flows which helped other dev teams in how the process worked (see below)
• Adoption in an org this size was interesting, but at least all the UX'ers meet bi-weekly and we did several demos for them
• One of the challenges was getting the designers used to working in Agile, and also in our tool, AzureDevOps and writing their own features and stories so we set some templates up for them
• We also had a brand new tool to learn, Supernova, which was our documentation tool and it was new to everyone (I really have to hand it to one of my devs, James Likely, for helping get that organized and the process going)

Challenges

1. SOWs: Lessons learned on inperpertation of the SOW. Get clarification before it is agreed to instead of after and being disappointed or worse.
2. Get training for the team approved before you start. None of the team had used Figma prior to starting so then learning a new tool and learning how to create components and documentation should have been done prior to anything else, not at the same time.
3. Setting guidelines and making sure everyone on the team knows what they are supposed to be doing and who gets to decide on making changes.
4. I set up a team of PM's, designers and vendors for a council on what we'd add to the design system and a priority grid for what came first. The challenge was some of the devs on the products were ahead of us, so deciding how to incorporate those items were more work for our devs and designers than we originally thought.
5. After the vendor was finished with their portion we had to assess what we had before we could release a version 1.0. Some code wasn't up to speed and a few of the early designs and documentation were awkward to work with. Getting everything set up in Supernova properly was also a challenge as it was a new product and constantly changing and improving.

So while we were assessing what we had, we initially concentrated on the Figma library. Getting that into shape was the first task. I came in later with some templates for the team to use to make sure they understood what the measurement of success was and to help define what done meant.

We did some usability testing and some card sorting to see how the designers wanted to see and use the documentation in Supernova. We found out that instead of one long page like the vendor had given us, they wanted it broken up into sections and so we made tabs in Supernova. Future testing will see if they liken reality what they said they wanted

In December of 2022 we released a v1 of the Figma libraries. Since I was also an admin for Figma I made them a global library available to everyone who had a Figma license. That way they just appear in the appearance panel and everyone can use them. Right away it made a huge difference and way more people started reaching out to see how they could utilize the Design System into their designs. (I created all the visuals for each component that sat in Supernova)

Exactly what you want to hear! When I did the quarterly webinar for leadership, instead of wondering how we’d get adoption or why we needed one now, we were getting kudos and everyone seemed super happy at where we finally were. I think in general, most folks don’t realize how long it takes to get a system in place. There is a fine line there where you feel like you have enough for a v1 and not enough vs is everything in a state you want to release. Luckily we had a great team and after we were done with the vendors engagement, we defined for ourselves what we wanted the design system to be and I am very proud of the release.

How we measured success

---

Measuring DesignOps is fairly easy. Are people adopting what you are doing? Is it making it easier for them to get their work done? Are the designers happy? Do they feel there is enough learning opportunities and are they being challenged to broaden their skills? Are they using the templates created and are those helping them to work closer with their stakeholders? And do those stakeholders also know how to work with UX and when to bring people in?

A Design System is easier to measure the success of and there are plenty of tools to help that happen. One of my favorite that is the easiest to watch is for the Figma libraries and which teams are using the libraries, which part of the libraries and most importantly is are they detaching components from the library. It allows for a great conversation with those teams that help explain why, if you need to change those components or something new is needed. At this writing, Supernova finally has SSO and we are still trying to get Google Analytics in. V1 is today, so we’ll see about getting good analytics there and we’ll do some more usability testing for sure.