Overview > Projects > Redesign - 2022

IMO Developer Portal

Redesign - 2022

Upon joining IMOHealth in 2021, my assessment of the organization’s design practice was one I find to be typical in mid-level enterprise software: The result of a poorly-understood craft being applied in ad hoc fashion by inexperienced practitioners at the behest of harried stakeholders. In a word, unintentional. Leadership didn’t realize it, but unintentional design was why the product I was brought on to resurrect failed in the market. So when that resurrection effort got tabled, I volunteered to work on a smaller initiative to demonstrate what a more comprehensive approach to UX could achieve.

Highs without a Face

Better than any other example from my portfolio, this project demonstrates the distinction between UX Design and UI Design. Because the below diagram was the most important artifact I delivered. Not a sexy sequence of high-res, pixel-perfect comps. Not a deck of splashy slideware. A nuts and bolts example of Steve Jobs’ famous adage, “design is how it works.” Not only did it solve the immediate design challenge, but set the organization alight as to the ROI of serious UX Design work.

Getting started: What was the problem we were trying to solve?

perspective overload

You can’t solve a problem until you know what it is.

And after a few meandering Zoom calls among a wide assortment of well-meaning cross-functional stakeholders, it seemed clear to me that we could agree on just one thing and not much else: That we wanted a nice new Web-site where our clients’ technical people could come and get the info and code they needed to establish API interoperability between their products and our data services. Beyond that, this challenge looked very different to each of them.

Knowing whom to ask

Early in my UX career, I had mistakenly assumed the stakeholder to whom I was most accountable for the success of a given project was the same person to whom I was most accountable generally at any given job — the UX Manager. This is inaccurate. Prevailing theory, as espoused by thought leader and author Marty Cagan, assures us it is, in fact, the PRODUCT MANAGER. I myself might argue that ultimately, it is the user. But for a good Product Manager, there should be no difference.

assembling an informal “discovery team”

What problem were we trying to solve?

As we’ve established, there were a lot of perspectives on this subject and the most important one was the Product Manager’s. Together, he and I would comprise two thirds of what Jeff Patton refers to in his seminal treatise, User Story Mapping, as a “Product Discovery Team.” Without their knowing it, or my even declaring it, I then added two tech leads to this informal team in my mind to round out the triad. See above.

Why informal? Because, as I describe in a different case study, the UX practice at this company was DWARFED by engineering and my instinct was that any high-falootin’ designer talk and pro forma finger-wagging on the subject of unfamiliar processes, no matter how appropriate, risked alienating the most influential team in the org. In short, I needed this company to associate real UX Design primarily with SUCCESS before associating it with exotic new concepts and changes to the way they operate. If people only hear what they understand, I needed to speak the universal language of “hey, that helped!”

Suffice to say, whether they knew it or not, by confining most of my interactions to the subset of stakeholders seated on my informal team, I had set us on a course for successful discovery.

Headwinds

As with all enterprise software projects ( or any human endeavor, really ), this project had its fair share of headwinds. Here are the top three I encountered and how I dealt with each.

Covid / remote only

The year was 2022 and this was a healthcare data company that employed doctors and other medically-minded people. An abundance of caution was the order of the day and a bunker mentality still gripped the nation. So even though most of us lived in the area, not one meeting about this project was held in person. At no time were we able to just gather in a room, close the door, order a pizza, and whiteboard our way through some decision points.

Apathy / Drift / Lack of Urgency

Unfortunately, this problem was endemic at IMO. In a company dominated by technical people, the realities of market opportunities and customer demand were almost always viewed through a lens of what Dev WANTED to build (never mind UX considerations!). As a direct result, a kind of learned helplessness pervaded whenever Dev wasn't onboard. And since they can't GET onboard till they understand the ask, a feedback loop is created, inviting drift and apathy.

Inexperienced Product Manager

Being an effective Product Manager is not an easy job. Unfortunately, the one assigned to this project was just not fully up to it. In his defense, our employer let Engineering intrude relentlessly into matters of product management. Regardless, this project needed a champion; a passionate leader to understand the value prop, promote enthusiasm, marshal resources, set deadlines, and partner with his UX Designer. At no point was nearly enough of this happening.

Research

Diamond in the bluff

The siren song of skipping right to design runs many software “ships” aground. Yet the idea persists that one can effectively design something one does not understand. If I’d tried to explain the ‘Double Diamond’ approach to design (below) BEFORE invoking it, I would be advertising we had a whole other “diamond” to transit before we started producing anything — something I knew would not fly for this org at this time. So instead, I unearthed complexity and let it speak for itself.

We shall come back to the diamonds here as a framework to track the forward movement I was able to generate for this effort.

Discover: Turning over rocks of complexity

So to re-cap, I had a design strategy, I was weathering a few headwinds, and I’d seated my unwitting Product Discovery Team. Now it was time to dig in with both hands.

I conducted a series of stakeholder interviews and unearthed a tangled mass of complexity. These sample artifacts (below) capture just the tiniest fraction of what I’d exhumed about the overlapping frameworks of data ingestion and human activity that was enabling users to leverage our APIs. There could be no viable new product without understanding this complexity. One does not perform surgery without understanding basic anatomy.

Define: Converging on the correct problem

The diagrams below, advancing in refinement from top to bottom, offer some insight into the definition effort. There were litle clouds of expertise around each step in the process, but no one had ever mapped it all out — until now.

Solving the problem

Achieving momentum and building confidence

I had helped this team clearly state the problem we were trying to solve. This was obviously an important milestone. But it was almost as important to have established some momentum. A breakthrough to spur on forward progress. As I’ve described, drift and apathy was one of our strongest headwinds. But now we were “beating to windward,” as it were, and picking up speed as we entered the design phase.

Driving cross-functional collaboration with user story maps

You can’t collaborate with someone if you don’t understand them.

And anyone who’s worked in software knows that developers, designers, and product people tend to speak in different “languages.” Developers tend to speak in technical jargon and code. Designers tend to speak in sketches and an altogether different jargon. Product people speak in lists and market demand and PowerPoint presentations (exceptional product managers are also able to translate between designer and developer jargon).

deriving (proto) personas from goals

Some of the most user-centric solutions in software arise, in part, out of the careful creation of “user personas.” When done correctly, this design process establishes a number of fictitious users to represent each kind of person you expect will engage with your solution. Obviously, the intent is to account for each of their discrete goals, contexts, perspectives, and abilities.

True personas require a fair amount of pro forma research, but in this case, since so many of our users were internal, we could settle for educated guesses, called “proto-personas.”

So, sometimes you can skimp on defining personas. But you cannot skimp on defining goals. You can’t have goal-directed design without them — obviously.

And goals are where user story maps start. In the above story map, the red sticky notes are the goals that we had identified. And as we refined and isolated these goals, more and better proto-personas came into focus. Some had two goals. Most had one. But the proto-persona with the most goals, we discovered, was the VIRTUAL one. The persona chosen to represent functions we thought we could AUTOMATE. We named this persona “Bucky Back-end.”

Bucky always got a giggle and helped loosen people up on calls. And of course, he’s not a real user. But the way he helped was driving cross-functional awareness as to just what steps COULD be automated and which other REAL users would benefit. in short, by showing us what he WOULD be doing, Bucky helped us understand what the other personas WOULD NOT be doing.

The Money Shot

I love a good diagram. In my experience, however, it takes splashy slideware or beautiful mockups to inspire the kind of enthusiasm for UX often required to motivate leadership buy-in.

Regrettably.

But not this time! The diagram I created to capture the desirable solution for this project went viral in the C-Suite and helped me achieve MY goal at this organization of getting them excited about the potential ROI of intentional UX Design.

solution breakdown

When compared to the problem diagram, we see the benefits: Total steps were reduced by almost a third. Internal touchpoints were reduced by nearly 60%. Number of environments were cut in half. As were necessary client steps. A crucial followup process was automated. And optional client exploratory activity was facilitated (raising maximum potential client steps to a mere eight from six).

Interaction Design ( IxD )

Let’s talk about wireframes for a sec

Low-fidelity wireframes are rarely interesting to anyone besides designers and the developers in the trenches. But since committing code is your organization’s last chance to prevent user dissatisfaction and re-factors, let’s see if we can’t make them broadly interesting for just a moment.

For developers, wireframes are a gold mine of answers they can refer to at code time, especially about the kind of edge-cases that don’t show up in sales pitches or marketing calls. In such contexts, no one ever talks about what to do when the user gets confused or frustrated. Or how the system should handle cases when the user makes a mistake or bails halfway through a workflow. Wireframes answer all the questions that start ‘what happens if?’

The Wire

As we’ve discussed, sometimes wireframes are appropriate because visual design is settled. Other times they’re appropriate because visual design is NOT settled. Sometimes the only parts of the design that need to be mature at code time are the Information Architecture and the IxD. Such was the case when I created the wire excerpted below for the vendor IMO hired to build the front end. Turns out my diagram revealed there was plenty to keep Dev busy on the back-end.

Outcomes

C-Level executives request a presentation on my UX Design process

I had successfully differentiated intentional UX Design work from what had been happening at IMO before I joined. And leadership had noticed. I was honored to be invited by IMO’s executive staff to present on the subject of the design processes I’d invoked for this project. Both the CTO and COO were in attendance, as were everyone they thought might benefit. In much of that presentation, I compared the old process to the new. See key slides below.

Two slides from the presentation I gave on my process for this project

lasting company-wide enthusiasm about ux

As I relate in a separate case study, IMO Health is an exciting organization that offers some of the most sought-after data services in the healthcare industry. And, for better or for worse, it is utterly dominated by technical people.

I had made this assessment early.

So breaking this company of old habits and getting them excited about what intentional UX design could accomplish meant getting Engineering excited.

The relationship between designer and developer can be tricky. Sometimes they have to tell us they can’t code what we’ve designed. And sometimes we have to tell them what they’ve coded is not what was designed.

Which is why I often analogize devs to construction workers who desperately want a good blueprint. Something that accurately describes just what it is they’re actually supposed to be building. In a word, CLARITY.

In an org dominated by technical people, demonstrating how UX can make THEIR lives easier was the key to evolving the entire company’s view of UX.

There is a key to ensuring the analogous “blueprint” the developers start coding from successfully imparts the necessary levels of clarity. And that is looping them into the design process as early and as often as possible. It’s tempting for designers, occasionally, as outnumbered by developers as we so often are, to retreat to our ivory towers and revert to bad habits. Heaving our beautiful designs over a wall and ignoring the fracas on the other side as we walk away shaking our heads.

But design can only help people if it’s coded. And to get it coded, you have to involve the coders.

Finished Product

It is important to note here that the vendor who built the front end made a number of choices I would not have made. And because they were modifying pre-built templates, our product manager saw fit to let them take liberties with the wire we gave them. Certainly not the first time consistency gave way to expedience in enterprise software.

Back to top

Compare the diagram capturing the solution (left) to the one capturing the problem:

Total steps were reduced by almost a third. Internal touchpoints were reduced by nearly 60%. Number of environments were cut in half. As were necessary client steps. A crucial followup process was automated. And optional client exploratory activity was facilitated (raising maximum potential client steps to a mere eight from six).

summary

When an organization is dominated by the engineering team, how does one designer get that org focused on improving their dysfunctional design practice to get better outcomes? By demonstrating at every stage of his first project the benefit to the dev teams involved.

This is the story of how, in the course of designing one product, I radically altered IMO Health’s UX strategy, leading to a tripling of their design staff.

When I started work on this project, fundamental UX Design strategies and processes were poorly understood and haphazardly embraced by a small and inexperienced design team. By unobtrusively invoking some of these design fundamentals at key junctures over the course of this project, I was able to navigate headwinds, establish a cadence of progress, and deliver useful outcomes through to completion.

By identifying the key stakeholders and showing them we would never design an appropriate solution until we had both a deep and broad understanding of the problem, I achieved momentum and mitigated the product manager’s inexperience.

Key victories included two elegant diagrams that Engineering regarded as supremely useful in describing both the problem we were trying to solve, and a solution worth pursuing.

These diagrams and word of other UX breakthroughs led to an invitation from leadership to present on these successes and what I’d done to achieve them. Shortly after, I was put in charge of design for their most strategically important projects. And within a year of that presentation, the UX staff was tripled.