Prototyping 201: Penny-wise, Pound Foolish
You won’t find any bigger proponents of the many benefits of prototyping enterprise apps than the gang at Propelics. Prototypes are an invaluable tool for validating the direction you want to take before spending big on developing the real-deal app.
Further, prototyping doesn’t just ensure you understand the use case, it affords you the freedom to re-envision underlying business processes via the magic of mobile. It also gives you a chance to gain feedback from real users (and other stakeholders) and integrate that feedback into the solution. In this manner, the first app release will knock the socks off your user base and any adoption challenges will disappear into the ether.
Prototyping is particularly valuable in the case of enterprise apps since these typically require multiple integrations to corporate data sources and platforms. Understanding early-on how the user interactions are going to work, and what data is needed (and when) saves a ton of time and effort when developing/adapting the APIs, web services or point-to-point integrations that will make the app work. In many cases, the development of these integrations can be more costly (both in terms of resources and time) than the development of the app itself.
While we’re at it, let’s also differentiate between a Prototype and Proof of Concept. “Wait,” you say. “Those are different things?” Darn tootin’.
While often conflated, Prototypes and POCs are not the same. Prototypes show how things could work—what the UI looks like, the workflow, even the physical design of the solution. POCs on the other hand answer the question: “can it be done at all?” These are adventures in technical feasibility. Can we make the app do what we want it to do? We don’t care what it looks like, just whether we can make it work and finding our best technical approach (bring on the Design of Experiments!).
I was in the middle of an intense App Scoping & Prototyping engagement when a friend called to ask about prototyping. He was surprised when I told him it was a 2-week engagement and we were working into the wee hours of the night.
For him prototypes were about giving the user a general idea about what’s possible or what the app might look like. He was proud of the fact that as they whiteboarded solutions with the client, the developer was busy assembling the screens and could deliver a rough approximation of the experience in a day or two. Just enough to bait the hook and land the project. In a nutshell his philosophy was: “close enough for government work.” But this isn’t our thinking on the subject and it’s not always sufficient to secure funding approval to move the project forward.
Now, I realize that light effort, low fidelity and green-lit projects is a great combination if you can get it. And perhaps it’s as much as some organizations expect to advance to the next step. But this only happens when the “buyer” can make a decision without input from other stakeholders. It also doesn’t promote the goal of ‘getting it right the first time’ when first unveiling the experience to users.
What I’ve found time and again (and this last engagement was a great example) is this. When it comes to prototyping, there are always huge benefits in going that extra mile.
There Are No Shortcuts
Well, actually, there are quite a few. The question is whether you consider the time and effort it takes to create a really great prototype as time well spent. At Propelics, the answer is obvious. We do.
When we build prototypes our goal is to create a gorgeous, pixel-perfect experience that follows a few key “happy-path” stories for a typical user or user personas. How we get there is no accident. We start with hand-drawn concepts and refine the UI/UX as we progress through wireframes to high-fidelity, full-color screens. At each step we play out the user story, think through the navigation across screens and screen elements, and take feedback from multiple stakeholders. The result is a superior, increasingly more polished experience. But going straight to (or bypassing) the wireframe phase or getting lazy and skipping the full-color designs simply can’t get you to this point.
The Difference Between a Happy Client and an Ecstatic One
Prior to Propelics I built plenty “good enough” prototypes. And the difference in how the client reacts at the end of the project has made me a believer that our process is hands-down the best.
It’s easy to say, “Who cares if you’re a few pixels off here and a few pixels off there.” But these days the bar for UX/UI is so high the “good enough” prototype winds up being more of a distraction than anything else. The amateurishness only causes those outside the process to focus on alignment/font/color mistakes rather than on how well the app functionality solves the user’s problems. This adversely affects the client’s emotional reaction to—and support for—the project and leads to a chorus of well-meaning UI improvement “suggestions” rather than inspiring more valuable feedback.
In my last prototype engagement we delivered a gorgeous, pixel perfect “raise-the-bar” prototype. Our client was ecstatic with the final product and fully invested throughout the process, which allowed us to think through not just design considerations, but workflow, required data and system elements. In this manner, we could more accurately estimate development costs and timeframes as well as identify any back-end system dependencies.
At the conclusion of the engagement, when we presented the prototype (or rather, had the client act out user stories in a live role-play) their enthusiasm shone through and the reception from senior leadership (who had not been involved up to this point) was phenomenal. Not only because of the enthusiasm of team members, but because they were blown away by the fit and finish of the prototype and could easily see how it successfully addressed key business issues.
Now we have the support to deliver the prototype to actual key users to validate our assumptions about how people will use the app. We’ll take that additional feedback and use it to build an even better v1.0.
Moral of the Story
When you think about your next mobile app prototype, consider this: in the grand scheme of things, an extra week won’t kill you. But skipping a few critical steps because you think it’s more efficient to do so can distract the client from what’s really important and lead to not getting your project funded at all. Worse yet, you could end up delivering a product that woefully misses the mark. #YouOnlyHaveOneChanceForAFirstImpression #PennywisePoundFoolish