Originally published at the IBM Center for Applied Insights blog.
Susanne Hupfer, IBM Center for Applied Insights, December 1, 2015
The IBM Center for Applied Insights recently completed a global study on mobile application development that uncovered some of the key traits of successful mobile development projects. To be considered successful, these projects met their deadlines, stayed within their budgets, and met or surpassed their primary business objectives.
One differentiator was that on successful projects, development teams were more likely to collaborate closely with the entire ecosystem throughout the project lifecycle, including quality assurance (QA), interaction designers, user experience experts, IT operations, business stakeholders and end users. In addition, three-fourths of successful projects collaborated using agile software development methods.
I recently had the opportunity to discuss the study findings with Brett Wachter, Center Executive for IBM Interactive Experience’s Chicago Studio. I was especially interested in hearing how he’s seeing our findings play out in the context of the real-world mobile development he directs at the Center.
S: What is your role with respect to mobile development at IBM?
B: I lead our Chicago Studio where we do much of our mobile experience design and development for the Apple/IBM partnership. I also have a mobile team that reports to me and is responsible for creative solutioning, development and testing for mobile applications.
S: Do you work on client applications or IBM enterprise mobile applications?
B: It’s a blend of both. Some applications are focused on enterprise mobile enablement — how do employees go about their jobs better by leveraging mobile? We also have clients from across industries that are asking us to build consumer applications.
S: In your experience, what’s one key factor that goes into making a mobile project successful?
B: The whole idea behind developing a mobile application is to make sure that you are focused on user-centric functionality.
The best mobile applications tend to do one thing really, really well — hail a cab, get checked into the airport… things along those lines. They don’t have this myriad of other functionality that surrounds them the way a website or other application might have.
If you try to pack too much functionality into a mobile application that should be focused and purposeful, then it really blows up the user experience to the point where it’s just unwieldy.
The thing that makes a mobile program successful from a scope, schedule and budget standpoint is a focus on the most crucial user needs.
S: So, in order to be successful, a mobile project needs to be relentlessly user-focused right from the start?
B: Yes. In the IBM Interactive Experience Chicago development studio, we use the IBM Design Thinking framework to apply user-centered design principles in an agile way to support product development engagements. We’re also using it in our own IBM software development.
The rationale is that if you’re zeroed in on the primary user task and needs, then all the other somewhat distracting features, functionality and capabilities that you might try to pack into a mobile application fall by the wayside. The more those distractions fall by the wayside, the more successful your project is going to be from a timeline and budget standpoint, because you’re continuing to focus on the most valuable and minimum viable product you can get into the market that’s going to solve and address key user needs.
S: In the study, we found that successful mobile projects are more likely to report having close, ongoing collaboration with both business stakeholders and end users throughout development. How important is it for mobile projects to have a close collaboration with the end users throughout?
B: That close collaboration is a core aspect of the user-centric principles that are a part of any design and development initiatives we do. That kind of interaction is becoming more and more integrated in the most successful programs.
It used to be, and still is to some degree, particularly when you’re doing the big initiatives like website design and development, that you’d do a significant amount of design work prototyping the experience, and then in the middle of it before moving into development, you’d have a big round of usability testing. You’d bring in 10-12 users and have them go through a script and bang away at the application and the experience design to find issues and determine whether users will be able to accomplish the desired tasks.
That’s still a common practice, but what we advocate more for now is having “sponsor users” who are part of the actual working team. These users spend their days co-creating side-by-side with the designers and developers who are trying to work their way through an application that will solve for the user problems.
In most instances, the designer or developer has to make very fast decisions on what kind of user interface elements and functionality are required. And because these projects are moving faster and faster in a more agile way, that constant need to refresh is occurring more and more frequently.
That increases the need to have a greater degree of collaboration, and for having sponsor users as actual members of the project team.
S: Is a “sponsor user” someone the client provides, who sits with the development team and plays a role all the way through?
B: There’s a difference between a stakeholder or business sponsor and a user or “sponsor user.” We do want to have stakeholders and business sponsors at the table, because they’re representing the Client’s needs (e.g., “I need to drive revenue” or “I need to reduce costs”).
But at the same time, they don’t always necessarily represent the actual user’s needs as crisply as you might want. Under ideal circumstances, you’d have the actual end user work with the mobile development team.
But that’s often hard to do, because that means you have to pull a hospital worker, for example, out of their day job to sit with the design and development team. You’re not always going to get that. In those cases, we fall back on a client who has deep industry expertise, someone who preferably was that practitioner in the field before moving into the corporate office who can then become that sponsor user.
S: So the sponsor user may be a proxy for an actual end user. But it’s someone who understands the end user needs extremely well…
B: Yes. There’s an overall co-creation mentality that we need to have where we bring the talent and the subject matter expertise for what creates a compelling user experience. The sponsor user brings the subject matter expertise for what truly gnaws away at a user and what we need to solve for them.
