Designing for Consumers in an Enterprise World

Published 31 Jan 2019

This was originally posted on TeleTracking's Design Blog.

Let’s set the stage. At TeleTracking, we have nearly three decades of experience building software that helps health systems provide patients with the care they need more efficiently. This means a large portfolio of enterprise products. And with that portfolio comes a lot of existing knowledge, habits, patterns, and technical debt to be accounted for; a lot to wrap my head around when I first started.

To get specific for a minute, that means that business as usual for TeleTracking is building enterprise software for specialized users who historically have been operating in very specific contexts. We have a great team and are continually improving and evolving our software, but the reality is that the vast majority of it is immensely complex, with a long history, viewed on large monitors. As a result, it’s supported only on specific desktop resolutions. Hardly unheard of in the enterprise software world.

Enter Community Scheduling & Workflow™ (CS&W).

Community Scheduling & Workflow™ is a relatively new solution for us. Newer code, though it’s still playing by the same rules as other solutions and only officially supporting desktop resolutions. It helps improve wait times and patient experience for ambulatory care centers and includes the ability for patients to schedule their own appointments.

The most important part here is patients can schedule their own appointments.

Up until CS&W, we were always designing for employees of a hospital or health system. These are people who use our software to do their job day after day.

Suddenly we’re also building a set of features targeted for a much larger group of people. It’s not something that will be used by the same person day after day any more. And it’s a publicly accessible website, so these users are definitely going to be accessing it with more devices than just desktop computers.

So what do you do when you join a team working on software for a new set of users and contexts, but continuing to build it as if it’s business as usual?

Talk About the Differences Early… #

This might be obvious, but I can’t stress it enough: Communication is key.

Designers don’t work in a vacuum, and as a new team member coming from the consumer software world, I had a useful outside perspective. But it wasn’t the only perspective, or even the most important one. TeleTracking is full of smart people with many years of experience in healthcare and in building these types of solutions. So I put my views out there and listened to what my coworkers had to say in response.

Fortunately we have a great team. Everyone was on board with the idea that patient self-scheduling functionality would sometimes need to be handled a bit differently than other solutions had been. The list of capabilities we could improve or change grew pretty quickly from these discussions.

… and Talk About Them Often #

I probably sounded like a broken record at some points, but mindsets and habits are hard to change, especially when they’ve been ingrained for years.

It’s easy to just lump our solutions together in the same bucket — one process and set of standards to rule them all.

So any time I noticed we were generalizing things, I piped up and pointed out that we may find CS&W could use a different set of patterns or requirements. The goal wasn’t to immediately demand a bunch of changes, it was to start changing mindsets so we are all thinking about our patient self-scheduling solution a little differently.

The persistence paid off. Over time others have started saying similar things as well, which is great to see. That’s always the goal—for everyone to be thinking critically about what we’re doing. It’s particularly important for us with CS&W because this is a new solution space.

Start User Testing ASAP #

Up until recently our experience with user testing has been in hospitals with very specialized users. Once we started talking in depth about the fact that our users could be anyone, we came to the realization that user testing for our patient self-scheduling functionality could be a lot simpler than it is for other solutions. As everyone has been a patient at some point in their lives, pretty much anyone could give us useful feedback.

To get us started, a team member posted in a company Slack channel asking for anyone interested in helping to test our patient self-scheduling functionality to react to her post with an emoji. That gave us a lot of folks to reach out to and start testing with, and the end result was a ton of valuable feedback that will inform our design work going forward.

Find the Quick Wins #

The byproduct of testing and talking to people on and outside your team is that you learn more and identify opportunities for improvement. It also starts to become apparent which opportunities are going to be easy wins, and which are going to take more time.

The list of things we’d like to improve is pretty large: accessibility, cross-browser support, testing (manual and automated), prototyping, and responsiveness just to name a few.

The important part is finding realistic and achievable goals to start making concrete improvements.

Thanks to the relatively small feature set in patient self-scheduling (compared to TeleTracking’s other solutions), we found we could pretty easily set a course for improving our standards in two key areas: accessibility and responsive design.

We have a great team and product manager who didn’t need to hear about legal risks to be on board with focusing on accessibility. And the design team had already been working to improve accessibility across all of TeleTracking’s products. The public-facing nature of patient self-scheduling just means it makes sense for us to prioritize it a little more, and the smaller scope of functionality helps us achieve it quickly.

As for responsive design, the “easy” win was a quick and dirty responsive retrofit. CS&W already uses a fair bit of Bootstrap, it just wasn’t being designed or developed to account for a variety of screen sizes. So going in after the fact to ensure that everything at least resized and scaled appropriately was a reasonable task. Changing how we design from the start to better accommodate mobile will be a larger process, but viewing responsive design as a requirement is a solid start.

Document the Differences & Decisions #

Talking about the differences between solutions and their contexts is all well and good, but if it’s not written down as a concrete part of what we do and what others reference, it’s harder for it to really stick long term.

The most valuable tool for designers here at TeleTracking is our Mosaic Design System.

Mosaic helps us build a cohesive platform and work more efficiently. Plus, our internal Mosaic website functions as a place for us to document patterns and processes for everyone to reference, helping us stay consistent.

So to start, we’ll be highlighting internally that supported browsers and screen sizes differ depending on whether or not the product is for a consumer audience.

Keep Pushing for Progress #

The process of improvement never stops, especially on a solution that’s so different from everything else being built around it. But the best part about having consumer-facing software in this enterprise world is that thanks to our collaborative team and our design system, almost everything we do to push our patient self-scheduling functionality forward can benefit the platform as a whole.

We don’t want to change things just to be different because the users of this product are different. But we do want to make sure we’re meeting (and exceeding!) our users’ needs. So when we do the work and find out changes from our standard patterns and processes are justified, we want to make sure we define and document them for future reference. That helps all of us work smarter instead of harder.