ux case study: run-and-gun responsiveness

brief background

In late spring of 2013, I was tapped by RealPage to unify three distinct Enterprise SaaS applications into a single suite under the LeaseStar brand. Each of these three applications was acquired separately from different companies. Each app served the same market but focused on separate parts of it, performing a discrete set of functions with only some overlap. And of course, not only did each app have its own distinct look and feel, but its own distinct way of doing things, too. Each had its own "UX sensibility." Where one showed a list of potential customers in a dropdown three screens in, the other showed them in a grid on the first page. Etcetera. Etcetera. So unifying these three applications meant not simply making their aesthetic agree, but their UX Sensibility, too. Indeed, this was not just an overhaul and not just a redesign. This was Product Design with all the requirements already expressed in the divergent experiences of three separate applications.

speed becomes priority number one

Responsiveness, while a must in the consumer market, was a new priority for the C-level stakeholders in this B2B project. To them, these apps were still something someone in a necktie pulled up on a computer in their office. And none of the three legacy products were responsive. I began to socialize the idea that this was the perfect opportunity to further outperform our competition by building a product our clients could pull up on their smartphones. In order to really make that case, however, I was going to need metrics. Unfortunately, the team-member in charge of metrics was on vacation and his under-study wasn't quite up to the task. Were any of our clients even trying to use these legacy apps in a mobile context? All anecdotal evidence suggested they were not. And because of a newly-emerging niche in our market, the need to be first to that market with a stable product serving that niche had already become the highest priority. Not only did a majority of stakeholders wish to proceed immediately, but to do so on the strength of just a few mockups I had submitted some weeks previous. Responsiveness would have to wait. Or so we thought.

fewer ways back

The only layout I had to this point devised for the new design was 1366x768 - the most generally popular resolution at that time (and as of this description) for computers, according to W3Schools. As I proceeded to wireframe the new product's general flow and those UX mechanisms it would share across the suite, I stressed flexibility in the layout so that we could come back to Responsive in future iterations. I did this by designing for logical breakpoints and making sure I introduced no screen sequence or interface mechanism that was inexorably wed to a desktop layout. Then came the pushback from Development: They could meet their milestones, but only if they could set aside some of the nuance described in my wireframes and stick to a fixed-width approach like they were used to. So while I was having my first substantive call with the Product Manager for the legacy product that would build-out the new niche functionality, the overall layout for the suite was in the process of being nailed to a 1366 frame.

why metrics are never optional

As we reviewed his product, Lead2Lease, what stood out most was its narrowness. This application was evidently so old that it had been designed back when the threat of a User coming at it with an 800x600 screen was still a possibility. I started to realize that of the three legacy apps going in to the new suite, this one could inadvertently have become the one most accessed by mobile devices because of its narrow layout. The PM was more concerned about the general modernity of his customers' computers. When I told him that, at that time, 1024 was at 7% and falling, he said "have you ever been to a leasing agent's office?" Apparently one shouldn't be surprised to see a Commodore green-screen in this setting. We agreed that what we needed was information and we needed it now. The Metrics guy was back from vacation and we got a full report on customer screen resolution fast-tracked. What it showed would put the whole timeline in jeopardy.

everything 1024 is new again

What it revealed was that nearly a fifth of our Users were looking at Lead2Lease at 1024 or smaller! If we proceeded as we were, almost 20% of our Users would be scrolling horizontally to fully view their global actions. One of these global actions was Search, a vital component in the app's general usage.

ux imperiled for 1 in 5 users

I try never to leave any User out, but in the inevitable usability triage created by aggressive timelines, implying to 7% of your Users that they ought to drop $500 on a new laptop falls within acceptable margins. Twenty percent, on the other hand, most definitely does not. For the PM, these findings were proof that he knew his Users and their antiquated habits. My sense was that we were both right, that a higher rate of his Users were still using old 1024 boxes but that another ten or so percent had decided that because the app was so narrow, zooming in a little on an iPad was a small price to pay for managing potential lessees on their train-ride home. And that this, in turn, was further proof that if you build it, they will come. If you provide mobile options, Users will embrace them. Regardless, I had to design a solution to this problem and do it without telling everyone we had to start over and build responsiveness in to the whole app.

run-and-gun solution

We needed a solution and we needed it fast. We didn’t have time for a responsiveness overhaul, but we couldn’t afford not to address the need for responsiveness in this one crucial instance. Not only did I have to get it right the first time, but the solution had to be extensible. That is, it couldn’t be some patch. It had to work for future, more responsive iterations of the application or even more time would be wasted untying the knot at the end of this round. What I designed and hurriedly wireframed for my front-end dev team I dubbed the ARSEON, for Abbreviated Right-Side Expandable Overlay Nav. When the browser width was narrowed beyond what could be encompassed at a width of 1024, the right-side array of labeled options collapsed into a thin, semi-transparent array of icons that expanded on mouseOver or onClick. We barely missed a beat. All of the stakeholders agreed it was as elegant a solution as we all could have asked for, regardless of the time-crunch. By keeping the need focused and making certain my Dev team had the level of wireframe descriptiveness they needed to get the job done, my team successfully threaded the needle.

View screen video of this solution in action here.

View a copy of the wireframe here.

© 2014, Gloor Product Design, All rights reserved
design is how it works