User Experience

We’re Fast to Mobile Market — but our UX SUCKS!

Fast to Mobile Market but our UX SUCKS

A conversation I had with a client this morning brought to mind an excellent research whitepaper published by Human Factors International (HFI), and is available via their website. It’s called Going Mobile? Speed is Fine, but UX Strategy is Final. It was published in 2012 originally, but the lessons contained within are eternal.

The basic premise is that while speed to market is important, UX strategy trumps it nine ways to Sunday.

Which of course brings a BIG, wide, cheshire cat smile to my face.

Consider the opening paragraph:

“Typically, the first foray into creating a mobile presence is a rushed affair . . . the development process does not allow companies to understand and appreciate the relevance and nuances of the mobile channel across three key aspects: business considerations, user engagement and technical capabilities.”

True dat, as the kids say. If I had a nickel for every time I tried to convince a client that they had to design and pour the foundation before building the house, I would be sitting on a backyard beach in Tahiti typing this. Most of us inherently know that you can’t build anything without a plan, right? And yet companies launch mobile apps every day without taking the time to figure out if anyone wants, needs, or will use what they’re launching. Too many nights watching Field of Dreams, I guess.

The HFI paper describes the development process most companies adopt as this:

  1. Identify business need
  2. Develop and debug
  3. Launch/Distribute
  4. Maintain/Retail

The problem with this is that in the mad rush to get something to market, they spend no time considering the three most important aspects of product strategy: business outcomes, user engagement and technical capability.

Business Considerations

First of all, the design processes and effort required don’t change just because the screen is smaller.

My own experience over the last three months alone proves out what the authors describe: companies all too often assume that designing and developing for a small screen size is somehow proportionally cheaper. But the context-specific ways in which users engage on mobile devices are myriad and complex, and demand a narrower, task-centric view than their large-screen counterparts.

And aside from that, consider how many different devices, fragmented systems and pixel ratios your mobile app or site or widget now needs to display and function properly on. More options to develop for = more money. Not a complicated equation, folks. Multiple versions of an interface have to be designed, developed and tested to cater to the majority of mobile users.

And even though everyone’s in a rush to get there first, time to market isn’t given proper consideration either. The publishing legalities alone can slow the process to a grinding halt. The HFI whitepaper offers the example of FreedomVOICE Systems, developer of the Newber iPhone app, who evidently learned this the hard way. After a full 165 days of radio silence from Apple, they simply abandoned the project altogether.

User Engagement

As you’ve heard from me more than once, all users have a core set of expectations, which create a “mental model” of how they expect things to work. They know what they want, they know when they want it and they know how they want it. sers have a strong mental model of how they expect to be serviced. And the producer of an app has zero control over that, because the model is built from a person’s psyche, expectations, emotions, needs, prior experience, etc. What they decide to do — what apps they do or don’t use and for what reasons — are dependent on their mental model, on how they see their world and how your product fits with that vision (or doesn’t).

Most companies simply don’t take the time to investigate what the user’s mental model is, and then determine how their offering fits in, how it can add value without disruption. They don’t invest, in other words, in solid user experience research or design. There’s no validation of any of the assumptions being made about what people will want from them or what they’ll be willing to use. What I see most is akin to what my Sicilian grandmother would do to see if the pasta was cooked: throw it against the wall and see if it sticks. Great for pasta, not so good for a quarter-million dollar investment.

There’s also a common assumption among organizations — or actions that suggest the assumption — that their app lives on a high pedestal in some kind of isolated vacuum. Look, any person who has a mobile device lives in a complex universe — and so do their apps and actions. There are multiple channels, players, relationships, scenarios, needs and opportunities. So whatever you put out there has to coexist in some manner with everything else. Channels have to be tied together, not separated. That bit of traditional business thinking is a dead end when it comes to the mobile universe. Users give less than a shit how your company is structured internally — all they know is they’ve got a fragmented experience that isn’t very positive or useful.

Technical Capabilities

With every opportunity comes an equal amount of challenge (and sometimes more). In this case, there’s a huge ongoing struggle within most organizations over the format of a mobile product: native app or browser-based?

Each has advantages, of course. Apps can take full advantage of the device’s native hardware, OS APIs and multiple innovative functions like camera, GPS, Accelerometer, Gyro, vibration motor, magnetic sensor and others. Browser-based products can’t. Native apps typically deliver better speed and responsiveness and a higher degree of control over visual quality and content.

However, there are times when a browser-based app — which is typically a cheaper alternative — fits the bill just fine. Because in some cases, users don’t want or need all that cool native stuff you’re adding into the app. But because companies often base their mobile strategy on what’s cool, what’s popular and what the competition is doing, they add a whole bunch of things that (a) add complexity, time and cost to the development effort and (b) do nothing to improve the user’s experience in any meaningful, valuable way.

Last Words

Authors Saurabh Gupta and Amber Krishan do a really thorough job of describing the place too many organizations find themselves in these days. If you’re one of them, I strongly suggest you download the whitepaper and share it with your colleagues. Discuss it in your next strategy meeting. Put any mobile plans you may have on permanent hold until you’ve had time to digest and absorb everything in here.

Why all the gravitas, you ask? One single, simple reason:

Creating something your customers don’t need, don’t want and won’t use is a terribly expensive proposition — in more ways than one. As the authors point out, you don’t just differentiate based on good user experience — you live and die by it.

  • Jérôme Lacroix

    Can’t believe how the HFI download form on their Ressources page sucks!

    Everytime you want to download a publication, you have to enter your info again, and for a reason I ignore, the form works “sometimes” when you click the Download button…

    Being a UX advocate and having bad UX is… well, you know what I mean. Hope they’ll fix this issue. Anyway, thanks for the link, HFI seems a good ressource.

    • http://givegoodux.com/ Joe Natoli

      I’m with you. And quite frankly, MANY of their website and UI practices are the exact opposite of some of the things they’re preaching. HFI falls more on what I call the “science” side of UX. They’re all about the usability and user-focused part, but the actual visual design and execution are nowhere to be found.

      I am a big fan of a lot of what they preach and the research they do, but there are too many groups like this — if you can’t get the visual part right, you do not have good UX. The visual part is the execution, it’s the way all of that great theory is made REAL.

Blog Categories