1. The Challenge of User Experience
4/28/2016 2:42:06 PM
The Challenge of User Experience
User Experience,Orasi,Agile
https://news-cdn.moonbeam.co/The-Challenge-of-User-Experience-App-Developer-Magazine_spiwpjsz.jpg
App Developer Magazine
Enterprise

The Challenge of User Experience


Thursday, April 28, 2016

Joe Schulz Joe Schulz

In the past year or so, user experience (UX) has been completely dominating the conversation around app development, pushing aside more traditional discussions. That’s not surprising, given user expectations - and the nature of mobile devices in particular. 

Yet, every day, thousands if not millions of users can’t complete  tasks because they weren’t intuitive enough, or weren’t tested on a sufficient number of devices and hang midway through completion, or any number of issues.

These are the realities of UX in 2016, and they are only the proverbial tip of the iceberg. Systems and transaction chains are more complex, the number of devices continues to grow, and users want to do more, but with fewer actions and less decision making. What are software teams to do?
 
At this stage of the game, the answer from my point is “answer the challenge or get out of the game.” Users are never going to accept poor quality. Thanks to the handful of organizations that are producing amazing products, they are only going to expect more over time.

Even with enterprise apps, long considered the bastion of “good enough is good,” user expectations are off the charts. And, since most users want to productively use their enterprise apps on mobile devices, the challenge of enterprise application design and execution is as great - and perhaps greater - than for mobile and web apps. 

The question becomes, how can we answer the challenge? It is my belief that change must take place individually, holistically, and collectively, all at the same time. That’s easier said than done, so let’s consider not only the problem but also some practical steps organizations can take to mitigate it.

The Reality Is Harsh

Users don’t want apps to simply open quickly and function well - they want apps that DO things outside the app interface. For example, why use a mobile weather app that only displays the current weather when you open it, when you want it to display pop-up alerts (and even text you) when severe weather is nearby? If it can exchange data with other apps to read your calendar, know you are leaving the house in half an hour, and remind you it is going to rain before your meeting ends, it’s even more valuable.

Making the situation worse, users also want functionality to extend across devices. Not only do apps need to work on Apple or Windows PCs and hundreds of tablet and phone models, to optimize the user experience, they should also support session and data portability so they can start a transaction on one device and complete it on another. 

In our weather scenario, let’s assume a user opens an app on an office PC to make a reservation at an open-air restaurant, but he or she stops when a “rain on the way” text arrives. If the weather clears after he or she leaves the office, the user would like to open the app’s mobile version and complete the reservation using session information saved on the PC.

Where We Are Is Exactly Where We Traveled

Before we dig deeper, here’s a bit of wisdom, written by another author, about UX. In a short blog entitled “User Experience Is Everyone’s Responsibility,” Dan Saffer wrote, “Each discipline can only go so far with the constraints they work under.” 

Saffer was accurately describing most organizations, and his comment would be appropriate today in a conversation about UX and software process design. However, Saffer didn’t write this in 2016. He posted it on May 20, 2008.

Seeing that date was a “wow” moment, even for me - and as an Orasi consultant, I speak to customers nearly daily about these problems. Eight years ago, Saffer nailed it, and yet we are still in the same situation. Saffer went on to finish his blog with this comment: “Focusing on the connective tissue between disciplines makes products holistic.”

I agree with Saffer, but I also believe that lack of connectivity is only one of the problems. Experience has shown me that the customary software process lifecycle is unsuited to meet current user expectations. Upper management is exacerbating the problem, because they cannot comprehend the problem - even though they are app users who experience it every day. 

Silos Are the Norm

At Orasi, we work with organizations trying to unite corporate applications from siloed departments into a composite framework that meets everyone’s needs. Yet in many organizations, the various software teams themselves are just as siloed. They hand work off; they don’t connect and collaborate. The “connective tissue,” as Saffer called it, is either missing or completely desiccated. 

Processes Do Not Address the Need

No company founded more than five years ago set up its software labs with the expectation of developing composite systems built of 10 or more apps - or testing on hundreds of devices, across transaction chains, and potentially involving thousands of third-party services. As a result, processes have grown organically in response to a challenge that morphs and moves constantly, and they are frequently outdated by the time they are developed.

Leadership Perpetuates the Problem

Organizational leadership likes to stratify data from operations by unit, with benchmarks that do not always correlate. That doesn’t work for a discipline, like software engineering, that transcends business units. 

For example, the marketing team providing UX input might be evaluated based on market share. Developers and testers, on the other hand, are being measured based on defects (and defect reduction). Quality assurance could bridge the gap, but its job is ensuring that the dev and test teams are meeting their coding and defect goals, not that their work is producing useful software. 

Team Members Feel Isolated

In this siloed environment with varied benchmarks, everyone may also be trying to do more than is possible given time and budget constraints. The mindset is often, “I’ll keep my head down and worry about my job. That’s what matters.” No one is asking themselves, “Is this application helpful to those who will use it?” 

The kicker is that companies may adopt agile in an effort to improve the situation, because the manifesto tells them: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” The manifesto, while wonderful, was written in 2001 when no one could have imagined where we would be today. 

For many firms, the “satisfy the customer” part has been buried by pressure to push out software rapidly with fewer defects. That leaves even less time for addressing the disconnect between software requirements and user requirements. (I use the term user requirements rather than UX, because it is a non-subjective term that translates well to software development and testing efforts.)

Fixing the Problem

This article isn’t about reengineering processes to proactively address UX. Process improvement should be an ongoing goal for all organizations, but it shouldn’t focus solely on UX. Optimally, it should be part of a larger quality effort that should also address technologies and techniques such as automation, reporting, and other mechanisms for ensuring better software, faster, with less effort. 

User expectations are evolving so rapidly that organizations need to address them today rather than postpone them for some future improvement effort. Manageable process tweaks can have a big effect in addressing UX directly. Here are three suggestions to get you started:

1. Look for the unexpected. Test for the way users shouldn’t work, as well as the way they should. Consider what happens when a user performs actions not only in the right order – ABCDE - but also ACDEB, BCAED, etc. How hard is it to get back to the right path? Do they have help or do they go down a rabbit hole and abandon the app? What happens when they attempt two or three operations simultaneously? 

For these types of tests, team members familiar with an app are not a reliable resource, because they know too much about it. Crowdsourced testing (where organizations work with a broad array of users at all experience levels and ask them to play with the app) is often the best source of input.

2. Build a meaningful feedback loop. All team members should be encouraged to think about user requirements as part of their work effort. For example, if during manual testing a team member notices that something really bizarre happened when he accidentally pushed the wrong button, he should be encouraged to report it, rather than dismissing it as not part of the test.

When the Ops folks report UX problems to QA, there should be a mechanism (and a requirement) for the quality team to pursue them and not simply ignore them once they confirm that no known defect matches that behavior. The company should have a mechanism to accept and validate these types of input and then include it in an update.

Most importantly, there must be a means for all feedback, once validated, to make it into the requirements - preferably within the same release cycle or one very soon after. Too often, feedback is ignored as being too expensive to address right away. By the time the next cycle rolls around, it is forgotten.

3. Make productive use of available tools. An arsenal of tools is available to monitor applications - not only in development and testing but also in production - where they can provide invaluable, real-world feedback on an impressive scale. Even though monitoring tools cannot replace the observations of real users, who can form empirical opinions, they can provide very valuable statistics. 

HPE AppPulse Mobile, which is part of HPE Mobile Center, is a good example. It monitors users from a transaction view, recording every step and then capturing and reporting on statistics about each user’s actions (right or wrong), the delay between each step, and how long the operation takes. Such a tool provides large-scale perspective. 

For example, it might tell the organization that among 5,000 users who attempted to complete an operation, 4,000 succeeded within a timeframe of five to 20 seconds. The other 1,000 couldn’t complete it the first time out, with 500 abandoning it after several tries. That’s powerful stuff.

The End Game

Making these adjustments may sound daunting, but they are unavoidable unless companies want to get out of the software development business altogether. The alternative is wasted effort and money—and potentially irreversible damage to corporate reputation and brand.

In short, users are becoming increasingly sophisticated, and they want highly intuitive, complex activities to happen seamlessly without their input. Experienced users - who are often key influencers - expect the technological equivalent of magic. As artificial intelligence and the Internet of Things continue to advance, those expectations will only escalate. 

The only practical solution is for organizations to accept this fact and embrace it. Those who do will enjoy not only increased user acceptance but also the satisfaction of achieving quality at all levels.


Read more: http://orasi.com
This content is made possible by a guest author, or sponsor; it is not written by and does not necessarily reflect the views of App Developer Magazine's editorial staff.

Subscribe to App Developer Magazine

Become a subscriber of App Developer Magazine for just $5.99 a month and take advantage of all these perks.

MEMBERS GET ACCESS TO

  • - Exclusive content from leaders in the industry
  • - Q&A articles from industry leaders
  • - Tips and tricks from the most successful developers weekly
  • - Monthly issues, including all 90+ back-issues since 2012
  • - Event discounts and early-bird signups
  • - Gain insight from top achievers in the app store
  • - Learn what tools to use, what SDK's to use, and more

    Subscribe here