UX Wireframing & 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, in this case for the services of mobile app developers to make an app that tracks inventory within the business' stores. You carefully poured over every aspect of the proposed app and decide to bid on the project along with a lot of 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 mobile app's coding and call the business' 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 it.
All ten marketing team members of the business upload 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' 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 to do so, 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 just needs some tweaking. Somebody finally asks why the business wasn’t more involved in the mobile app development process. Unfortunately, the question should have been addressed initially with storyboarding and wireframing and all of these problems could have been avoided.
Understand that the business is at fault for not knowing about storyboarding and wireframing and failing to include it in their Request For Proposal. 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 and/or disappointed with the mobile app’s launch.
Different mobile app developers will give varied definitions of wireframing. As a matter of fact, some don’t believe in wireframing at all and see it as a waste of time. The best definition of wireframing is that its a visual guide that represents the skeletal framework of a mobile app or website. Wireframing is essentially a GUI blueprint, sometimes called a schematic or mockup of how a mobile app will eventually look and behave. Wireframes are generated to arrange mobile app elements like intro screens, slider bars, buttons, etc. to best achieve a specific purpose. Wireframing is a business best practice and an integral part of business mobile app development and should never be left out, especially in a business environment!
Many mobile app developers do their wireframing with pencil and paper, which is fine if it is just for their own reference and conceptualization. However, pencil and paper wireframing needs to be committed to good wireframing software. Sharing rough pencil and paper sketches of wireframes with a client in a business setting is wholly unprofessional. Modern wireframing software will let you develop a mobile app in a logical, step-by-step progression and then share it with business clients around the globe during development. Professional “wireframers” are often called UX Professionals, a quasi-acronym that means User Experience Professional. UX pros often make sure mobile apps have the right “feel” and are ergonomically easy to use.
Choosing the Best Wireframing Software for UX Professionals
There are many wireframing softwares in the marketplace. “Top ten” wireframing software lists are littered throughout the Internet and can be completely different from one another, so choosing the right product is difficult. The first criterion for great wireframing software is the same for virtually all software: is it easy to use? Ease-of-use is often overlooked and shouldn’t be. You’ll appreciate it when you’re up against a deadline and not struggling to figure something out.
The next criterion for wireframing software has to do with where it lives; is it browser based? Popular wireframing software like HotGloo.com and Balsamiq.com live on the Web and require no installation, only a browser like Firefox or Google Chrome. Browser-based wireframing makes it incredibly easy to share mockups, schematics, and storyboards with clients and other mobile app developers. Imagine a virtual meeting where your client is looking at a mockup of their future mobile app through your online, browser-based wireframing software. When they request changes, you do them instantly while they watch. Browser-based wireframing also means you are not tied to a singular computer that has “installed” wireframing software. Your wireframes are truly anywhere in the world that has a computer and Internet access.
Some wireframing software can develop “Click Through Prototypes (CTPs)” like Adobe’s Xd. Adobe Xd’s wireframing capabilities can easily make a CTP by linking several screens via hotspots. A hotspot is a screen that interacts by clicking or tapping GUI elements to direct the user to a target screen. A single hotspot screen may have many redirecting elements to multiple screens, allowing the mobile app developer to put together complicated flows without having to focus on programming interactivity. Essentially, the Click Through Prototype looks and acts like a finished app, but without the programming. This encourages a Participatory Design environment where all stakeholders involved can be part of the mobile app development process. Many hardcore UX professionals still believe pencil and paper is the best way to make Click Through Prototypes, but that is quickly being replaced by the rapid evolution of wireframing software like Adobe Xd and its amazing array of easy-to-use, interactive, built-in tools for sketching, widget building, hotspots, etc.
Some claim that choosing wireframing software has a lot to do with your type of workflow. A small set of mobile app developers say that if you work alone, you should continue to use a pencil and notebook and ignore software altogether. This is old thinking and doesn’t work in any kind of professional business environment. Similarly, using a dry-erase whiteboard for wireframing in a team setting is quickly becoming an arcane practice as well. In business, using pencils, paper, and whiteboards is like using a calculator and a yellow legal pad instead of a spreadsheet. Your sketches and legal pads send a message in business, and not a good one. Is a potential client wondering if rough sketches are as far as you’ve evolved as a mobile app developer? Are they asking themselves what it’s going to be like to work with you? Unfortunately, you’ll never know because they won’t choose your bid.
Business best practice workflows that integrate wireframing software to foster a distributed, participatory design environment also send a message. The message is that you and/or your team know what they’re doing. They know that wireframing software also provides a historical record of a mobile app’s development, the same way as a System Development Lifecycle (SDLC).
Another discussion within the UX (user experience professional) community is fidelity. In the UX world, Low Fidelity is a hand-sketched prototype on paper whereas High Fidelity is a realistic and detailed interactive representation of a potential mobile app. Some would argue that low fidelity is low-cost and fast but lacks in other areas like online sharing and team development methodologies.
High fidelity has the advantage of providing an actual user experience (UX), putting a mobile app directly in a client’s hand and letting them test it as a prototype. However, high fidelity is thought to be expensive and slow. That is old thinking. High fidelity prototypes with wireframing software are so fast, inexpensive, and easy to generate that they have replaced the need for low fidelity methods altogether. High fidelity prototypes got a bad name in the past because they were actually programmed in software development kits (SDKs), which took vast amounts of time, involved a programmer, and were very difficult to change. Everything changed with modern UX wireframing software like Adobe Xd that offer drag-and-drop images, endless libraries of icons and fonts, and working GUI elements that don’t require any programming. Great UX wireframing software made high fidelity prototypes a standard, and even spawned UX designer careers.
Starting the Wireframing Process
The most important aspect of starting a wireframe is to really know what you want from your mobile app. Before you’ve even started, you should have already brainstormed and conceptualized what the mobile app’s wireframe structure looks like and what it will do. Wireframing can be part of the conceptualization process because it often reveals new opportunities you may not have considered, but for the most part, you should already have a clear idea of the mobile app’s wireframe outcome. If you must use paper, make a screen inventory list of sorts, so you don’t forget to include all of the mobile app’s wireframe elements. It is still a better idea to make your screen inventory list on a digital document!
Once you start committing screens to a wireframe, it’s best to use plain grey boxes and default fonts. At this point, it’s a big mistake to worry about details. Your main concern is to concentrate on the screens (boxes) of the mobile app’s wireframe. For right now, don’t even worry about how the boxes are connected, just stick to the screens your wireframe needs. This is not about what font will look best, button colors, slider bars, swiping, etc. All of these aspects are important, but focusing on minute details at the start will impede your ability to get a solid, working wireframe. From a business standpoint, you do not want your client thinking about anything other than the structure of the mobile app, the same way architects focus on the building first, and then move on to interior design later.
UX wireframes software comes with hundreds, sometimes thousands of generic screen templates that you can assign to the grey boxes you’ve laid out. Once again, it’s important not to get bogged down with details. This is no time to reinvent the wheel. You can edit any template you’ve chosen, but the idea is to convey structure at this point, so keep editing to a minimum. Now is a really good time to check your screen inventory list to make sure you’ve included everything. A pitfall to avoid is to not forget to update your screen inventory list should you add a screen on the fly that wasn’t originally included.
Keep in mind that you don’t have to get the wireframe right the first time. As a matter of fact, you should plan on making several independent wireframes for the same mobile app. You can take the best aspects of several wireframes and make them into one. At this point, you have a great opportunity for an online participatory design meeting to share even the most basic wireframe options with colleagues and clients for their opinions and suggestions, and frankly, to make sure you haven’t left anything out. (Most good UX wireframe software will let you make notes on the wireframe as needed during your online meeting.) Because there are no specific details like photos, or fonts in the wireframe, your audience will tend to focus on structure and not get off track with details that don’t matter at this point. On the other hand, there is a legitimate school of thought that encourages the UX designer to include aspects of a business’ corporate image, like their logo and corporate colors. UX wireframe software makes changing colors and adding images so easy and seamless that it might be a good idea at this point, but only at a minimum! Many UX designers say that adding corporate elements conveys professionalism and makes their clients feel that their eventual mobile app will be unique.
Once the screens are laid out in the wireframe, it’s time to focus on what many UX wireframe designers call a Splashscreen. Some UX designers refer to Splashscreens (sometimes called a Launchscreen) as a “user launch experience.” The Splashscreen is the first image your user sees when the mobile app is opened. Think of it as your mobile app’s first impression.
Splashscreens only have a few guidelines that must be adhered too, starting with size, or more accurately, resolution. Just because your Splashscreen looks great on the newest iPhone, doesn’t mean it will look great on older iPhones. As a matter of fact, it might not work at all on older iPhones. Eventually, you may have to make three different size Splashscreens for the same iPhone mobile app. Think small, medium, and large (hi-resolution). Android apps have potentially dozens of Splashscreen sizes.
A typical splashscreen only displays for a matter of seconds until the main part of mobile app begins. This means that Splashscreens should be devoid of text, unless it is a very short, very readable company motto. Splashscreens should basically include a business’ logo and/or brand name, and always centered. You may be tempted to align a business’ logo to the right, left, top, or bottom, but you will regret that decision when you have to crop the Splashscreen for different screen resolutions. Keep in mind that when the user sees a Splashscreen, the mobile app is actually loading in the background. Some UX designers insist that Splashscreens include a message saying: “Loading…” to let the user know that the mobile app is working and not hung up.
Fortunately, for UX wireframing, you only need one Splashscreen. You can leave the splashscreen grey with a generic logo, or use your business’ logo and corporate colors. Keep in mind that this stage of the wireframe is still about structure and not details. Once the Splashscreen is done “splashing” for a few seconds, it immediately goes to the Home Screen.
Home Screens used to be called “start screens,” but that became confusing relative to Splashscreens that essentially are the “start” of a mobile app. The Home Screen is where your mobile app really begins and is considered the main screen where navigation can commence. Home Screen’s can be configured in an infinite variety of ways, but there are some guidelines to follow. For instance, in UX/wireframing environments, a Home Screen should never include or generate a scroll bar. Scroll bars are generated by the operating system of a mobile device when it sees an image that goes beyond the vertical or horizontal boundaries of its screen. Problems can arise when scroll bars appears only when a user is swiping a screen. From a visual standpoint, when scroll bars are sometimes invisible because they’re not in use (in context), a user may miss certain navigation elements below the bottom edge of a mobile device that don’t appear on the Home Screen because they are simply not aware that they exist.
Now that your wireframe includes a Home Screen, it’s time to decide where you want your user to go. Most mobile app game’s Home Screens include a background image and a “start” button. The obvious implication is that when the user hits “start,” the game begins. A third screen is now required in the wireframe for where the game commences. Does the wireframe require new screens depending on the context of the game?
Maybe your mobile app isn’t a game and you want to give your user more options than just a start button. A lot of mobile apps, like an inventory app, resemble miniature websites. Keep in mind that websites enjoy a much bigger screen area than a mobile device. It’s time to make some decisions, specifically, where the wireframe goes next; another opportunity for an online participatory design meeting. The question is; where do you want your user to go?