UX Wireframing and Storyboarding

You're awarded a contract to program a mobile app for a large business. After completing the app, you return to the company to demonstrate the finished product. What could go wrong? Let's say that you completed every possible criteria of their RFP. RFP is an acronym meaning request for proposal, which is a document that solicits a proposal for products or services from a supplier. In this case, the business is requesting bids for the services of mobile app developers to make an app that tracks inventory within the business's stores. You carefully pore over every aspect of the proposed app and decide to bid on the project, along with many other mobile app developers. You find out your bid is acceptable to the business and begin programming immediately, hoping to impress. The business seems impatient to see the app, but you assure them that you will complete it on time for their launch date.

You finally complete the coding for the mobile app and call the business's marketing department to give a demonstration. You've decided to bolster your demo with a PowerPoint presentation so everyone in the meeting is clear on how the new inventory app works. Again, the business wonders what took so long, but you're sure any problems will be allayed once they see and use the app.

All 10 members of the business's marketing team download your inventory app and start clicking buttons, sliding screens, and generally searching through the app. Somebody comments that they don't understand why the inventory screen is so hard to find. Somebody else doesn't like where the business's logo is placed, and somebody's app simply won't load. The mobile app launch demonstration is quickly becoming a disaster, and your reputation is heading south rapidly. You desperately try to reel in the meeting, but the barrage of bad comments continues. In your head you know that every problem can be addressed, but reprogramming will take forever for a business that needed the mobile app done yesterday.

You also know that the reprogramming will extend the project’s launch date way past what you promised. From your standpoint, it will take three times as long as you had originally guaranteed in your RFP bid. A quick cost analysis in your head tells you two-thirds has been cut out of your hourly rate. You try desperately to explain that “technically” the app works, but it just needs some tweaking. Somebody finally asks why the business wasn’t more involved in the mobile app development process. Unfortunately, this question should have been addressed initially with storyboarding and wireframing. All of these problems could have been avoided.

Figure 4.1: . . . what they thought of your mobile app.

Understand that the business is at fault for not knowing about storyboarding and wireframing and failing to include it in their RFP. The mobile app developer in the previous example is very much at fault as well for ignoring wireframing in their bid to support a participatory design environment. Any good mobile app developer chosen should have included wireframing conferences throughout the development process with the large corporation so no one is surprised or disappointed with the mobile app's launch.