Projects > Redesign - 2022

IMO Developer Portal

Redesign - 2022

Within two weeks of my start date at IMO in September of 2021, the project I was brought on to help with was put on hold indefinitely. Why? I was about to find out. To make myself useful, I volunteered to work on a smaller effort to redesign IMO’s struggling Developer Portal. Doing so would give me a front row seat to the endemic design ingestion problems IMO, like so many growth-state companies, was experiencing. Through careful evangelism, expressed almost entirely as a measure of my success delivering for this project, I was able to break the design logjam and evolve IMO’s UX practice.

Here’s how.

UX Minus UI

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. This was instead a nuts and bolts example of the adage, “design is how it works.” Not only did it solve the immediate design challenge, but additionally set the organization alight as to the ROI of serious UX.

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

Why an INFORMAL Discovery Team? Existing mainly inside my head?

Because, as I describe above, 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 fancy and unfamiliar processes, no matter how appropriate, risked alienating the most influential team in the org — the engineers. In short, I needed this company to associate real UX Design primarily with SUCCESS. And do so 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 discovery team, I had set us on a course for success.

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.

Apathy / Drift / Lack of Urgency

Unfortunately, drift 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 result, a kind of learned helplessness pervaded whenever Dev wasn't onboard. And since Dev 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, as I’ve described, the considerations of Engineering tended to intrude into product management at IMO. Regardless, this project needed a champion; a passionate leader to understand the value prop, promote enthusiasm, marshal resources, set deadlines, and partner with UX. At no point was nearly enough of this happening.

Research

Diamond in the bluff

The siren song of skipping right to design runs many a software “ship” aground. Yet the idea persists that one can effectively design something one does not understand. The ‘Double Diamond’ model of the design process reminds us to never do that. But if I had tried to EXPLAIN this model to stakeholders BEFORE invoking it, I would be advertising that we had a whole other “diamond” to transit before we started producing anything. I knew that would not fly for this org at this time.

So, as with my unseen Discovery Team, I adhered to the diamond model without explicitly saying so. Instead, I unearthed complexity and let it do the speaking for me.

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

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 little islands of expertise around each step in the process I was capturing, but no one had ever connected them and mapped it all out. Until now.

The problem

So what, at the end of the day, WAS the problem we all needed to solve? Essentially, we had too many steps to our API onboarding process, too many internal touchpoints, and too many environments. Worse, none of it was leveraging our newfound capacity for automating at least some of this.

Solving the problem

Achieving momentum

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 can’t understand what they’re saying. 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 talk and PowerPoint presentations (exceptional product managers are additionally able to “speak” designer and developer).

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 personas had two goals. Most had one. But the 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 by driving cross-functional awareness as to just what steps COULD be automated. This in turn revealed 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.

game-changing diagram

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

But not this time!

The diagram I created (below) 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.

The solution

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 portal’s 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’ve described, IMO Health is an exciting organization that offers some of the most sought-after data services in the healthcare industry. And, for better or worse, its product teams are 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 really just want a good blueprint. Something that accurately describes exactly what it is they’re supposed to be building.

There is a key to ensuring this 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 start 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.

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.

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.

• Number of necessary client steps were cut in half.

• A crucial followup process was automated.

• And optional client exploratory activity was facilitated (raising maximum potential client steps to a mere eight from six).

executive summary of my work on this project

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 phase 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 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 at each step on the path 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.