Overview > Projects > Product Design - 2014

Product Design

By 2013, the property management software firm RealPage had made a number of acquisitions in its industry, inheriting the signature products of each. LeaseStar represented a monumental, year-long, phase-1 effort to merge three of these products into a single, unified, paid, enterprise service and I was in charge of designing it. As I describe this project, I will be putting my key design decisions in the context of the UX theory that inspired them. Along the way, we’ll meet some of the best minds in UX today.

about the visual design of this product

The final look-and-feel of this product at launch was essentially a compromise among a number of key stakeholders, not the least of whom was a Vice President at the RealPage home office in Texas who ultimately pushed for this direction.

I had originally advocated for something much bolder and all my initial moodboards reflected visual design directions more in keeping with cutting-edge styles of the day while retaining an emphasis on utility.

The real strength of this experience is clarity, logic and usability. There is never any doubt about where you are in this SaaS, what’s selected, and what you can do next. Our personae were mostly busy leasing agents who were just as likely as not to be using this application while talking on the phone. Notice how starkly the orange calls-to-action stand out against the shades of contrasting blues.

Information Architecture (IA) …

why structure matters

A beautiful User Interface is an important part of the user’s experience of your enterprise solution. But it is no substitute for properly architecting the product’s overall structure. Navigation, for example, is crucial for more reasons than might at first seem obvious. Sure, a good navigational system tells you where you are and where you can go next.

But as Steve Krug reminds us in his influential book on usability, ‘Don’t Make Me Think, Revisited (New Riders, 2014),’ navigation serves three other, hidden purposes: First, as Krug puts it, navigation “tells us what’s here.” By which he means it reveals content and helps you understand the POINT of the application.

Second, Krug reminds us that navigation tells us HOW to USE the site. Krug writes “If the navigation is doing its job, it tells you IMPLICITLY where to begin and what your options are. Done correctly, it should be all the instructions you need (emphasis added).”

And third, when you’ve properly architected the navigational system of your product, you’re imbuing users with confidence in yourself and your product. As Krug says, “Every moment we’re in a Web-site, we’re keeping a mental running tally: ‘Do these guys know what they’re doing?’”

prioritizing visual appeal (of the app, not the deliverables)

It’s always been a source of some amusement for me when I see UX Designers and their managers stressing over how attractive a specification document is. How beautiful are its diagrams? Are they color-coordinated? What about the font for this Experience Map? What will the head of Product say?

It’s like a carpenter worrying about what color his hammer is.

OCCASIONALLY, a UX Designer’s deliverables must be presented to powerful stakeholders and even potential customers. In such cases, curb appeal will inevitably be a factor. But most of a UX Designer’s spec documents are intended to be consumed by Developers over what is typically a very short amount of time. If you’re rocking and rolling the way you should be, the relevance of these deliverables will utterly evaporate in a month or two. Indeed, as UX savant Jeff Gothelf writes in his foundational book, ‘Lean UX (O’Reilly, 2013): “Putting in [high levels] of polish and effort into the early stage artifacts — wireframes, sitemaps, and workflow diagrams — is a waste of time.”

This motley array of excerpts from some of my earliest IA artifacts for this project are excellent examples of this criterion in action. Developers do not care how pretty your IA Spec is. They only care how clear it is and how complete it is. Expect my documentation to be conceptual, inventive, and occasionally a little wry. But unless clients are involved, also expect them to be above all PRACTICAL.

In the end, the only artifact that truly counts is an effective and yes, attractive application delivered on time and on budget. Like this one was. Exactly none of your users are going to care about the documentation that went into building a product they love to use. They WILL care about documentation, however, if you require them to read training manuals to use your product.

And not in a good way.

Interaction Design (IxD) …

who is designing your product’s behavior?

Over the course of an enterprise SDLC, hundreds of sober decisions need to be made about how your product will behave and how this behavior will vary in different scenarios. Who on your team is going to make these decisions?

The Developer? She’s focused on code-complete and “velocity.” Being inventive and thinking about the user only makes more work for her that wasn’t there before. Regardless, you don’t want Developers making UX decisions on their own. As UX giant Alan Cooper writes in the fourth edition of the IxD bible ‘About Face (Wiley, 2014):’ “Developers [design] product behaviors in the same way that miners end up ‘designing’ a landscape filled with cavernous pits and piles of rubble.”

notifications

A selling point of this solution was that it would provide users with timely and compelling reminders about things like appointments in-screen. To ensure the user did not become desensitized to these reminders or experienced them erroneously, a number of subtle conditionalities had to be worked through. When do such reminders occur? When do they become irrelevant? What do they look like at each stage? On the right we see an excerpt from my spec on the subject and left, the result in-app.

UX and the Business Side …

A UX Designer’s relationship with his Product Manager is arguably the most important relationship in software design. The importance of this relationship is a central theme of Marty Cagan’s seminal book on product management, ‘Inspired: How to Create Products Customers Love’ (SVPG Press 2008).

And the significance of this relationship was tripled in this case. As I’ve described, the point of this project was to merge three discrete enterprise products into a single, unified SaaS. Each were the signature products of firms acquired by RealPage. This meant each product came with a legacy Product Manager from the acquisition who had stayed on as a RealPage employee. They would each now manage the section of this massive SaaS that their product would become. And they would work with me to facilitate this transformation.

Each of these three product managers had exercised some degree of control over their product’s UX, either directly or indirectly through a legacy designer. But now I was the only designer of record. Needless to say, some of these Product Managers were not always thrilled their ideas on design would have to go through me.

One in particular, a Mr. Mark Richards, had patiently worked with me after his new boss had repeatedly told him he would no longer be dictating design decisions. But eventually Mark drew a line in the sand and insisted a button be removed from the product’s “ribbon.” And this created two tough issues:

First, demarcation. Mark was having a hard time adjusting to the responsibilities his new role exactly encompassed. And in this case, what responsibilities his new role did NOT encompass. Product Managers should NOT be making design decisions. They should manage by OBJECTIVE. As in, they discover WHAT things would be valuable for their product to do. But HOW the product does these valuable things is the province of the DESIGNER.

The second issue was the fact of this particular design request. He said the button had no business being there. But I knew that removing it would impede the user.

I decided to address the first issue by confronting the second issue head-on.

usability thunderdome: Two designs enter, one design leaves

No one likes to be proved wrong, so I always try to maintain as collegial a design environment as I can. But in this case, I felt it was necessary to show Mark that he could trust me and that his design opinions did not always align to his users’ reality. My hypothesis was that removing the button would hinder the user in performing a function that was central to the product’s purpose. Mark’s hypothesis was that it wouldn’t. So I formulated a quantitative usability test for each scenario.

These were the instructions twenty test participants were given for both his design and mine:

You are a leasing agent beginning your day. Someone just called you and said they're thinking of renting an apartment in the building you work for. Such people are called "Prospects." You must now add a Prospect record in this application. Where would you click?

Obviously, the results speak for themselves.

When I shared this evidence with Mark, I was concerned he would consider it some sort of escalation and be resentful. But the opposite was true. I learned from this experience that nothing defuses a disagreement quicker than hard evidence. Since this episode, I’ve learned to rely on tests like these to settle most similar disputes instantaneously. Mark and I moved on constructively. Him with a better appreciation of the complexities involved. Me with a vital professional relationship intact.

Result …

I designed the entirety of this product’s UX. From its overall conceptual model, to its organization, labeling, and navigation systems, to every one of its workflows. From its look-and-feel to the various tests I wrote to ensure optimal usability. Considering where my team started, the scope, the schedule, the political and financial pressures involved, it was no small feat to have produced a 1.0 version in just over a year.