User Experience (UX) in Business
A tourism board wants a Wine Tour mobile app to increase commerce, specifically in the Pacific Northwest’s Columbia River Gorge. However, they have stipulated that if your team doesn’t deliver the UX wireframe on time, you won’t get paid. This isn’t a random mobile app game you’ve been picking at for a few months at home and might eventually deploy; this is real business. There is more than just money riding on this RFP as well; your company’s reputation is at stake. A perceived bad reputation in business can be hard to overcome and sometimes fatal.
UX wireframing will help both you and the tourism board reach consensus of how the proposed “Wine Tour” mobile app will look and feel, and how it works before any programming occurs. Programming takes way too long, and is difficult to modify when changes are needed. Further, the role of a professional coder is to program, not necessarily design what the user will eventually get. The UX professional on the other hand creates a participatory design environment with the business to determine exactly what the mobile app user will ultimately see and experience. Once the UX wireframe is done, specifications and assets are passed on to the programmer for them to program and complete.
It might feel like a mistake to include UX wireframing as an extra step before programming; it’s not. UX wireframing is an enormous timesaver that provides many advantages that assure success of the mobile app process. Consider for a moment that you’re building cars instead of mobile apps. Would you simply let mechanics (programmers) build a car based on what they think (paper storyboards) the company wants? What happens after they build the car and it isn’t exactly right? With a great deal of time and effort, the mechanics can modify (reprogram) or even rebuild the car, and submit it again for approval. On the other hand, UX wireframers can show exactly what the car will look like in a participatory design environment before it’s manufactured. The UX wireframing process will even produce parts (image assets, splashscreens, etc.) for the car that mechanics can use to save time.
Many businesses are unsure of what they want when it comes to mobile apps. They may not know what their mobile app should ultimately do, in large part because they don’t know their options. Often times during the participatory design process when the UX wireframing team and the business meet, new opportunities are revealed that the business wasn’t previously aware of like navigational elements and database access.
To get off to a good start, you choose Adobe’s Xd as its UX wireframing software, and for many good reasons. Adobe is a cutting-edge, global leader that has been around for many decades. You could have chosen a smaller, more inexpensive browser-based UX wireframing software, but you are unwilling to risk your reputation because they went out of business, or don’t have the features or support you need for an online professional work environment. You choose Adobe Xd because you don’t take unnecessary chances.
The first step is to meet with the tourism board and ask what they think their mobile app will do, and how they see it working. Keep in mind, the tourism board has no UX design or programming experience, so many of the options that are available are not known to them. Part of your job is to make them aware of all options available without undermining their vision. Your first goal is to agree on basic screens, rank them in order of importance, and then figure out navigation. It is of utmost importance that you do not waste time on minutia. Make sure the tourism board knows that all ideas are considered and can be implemented, but at the start, the basics are most important. For instance, one of the tourism board members wants to know if the mobile app user can share their wine opinions on Instagram. The answer is yes, but right now, it’s more important to focus on basic framework, the same way a car designer focus’ on engines and wheels before deciding on paint color. It is also important to not dismiss any ideas, especially from the client.
The tourism board describes their potential mobile app as an efficient way for a wine connoisseur to travel through the states of Washington and Oregon and taste the specific wines their customer’s want. For instance, a user of the potential app may like red wines, but not white wines. The user would be able to enter this information in the app that would in turn direct them to wineries that only produced red wines. Further, the app needs to be smart enough to guide its users from one winery to the next in the shortest distance. Rather than simply list wineries that produce red wines, the app needs to provide a map and calculate the most efficient routes from one to another.
Understanding the Business
You already know some of the UX objects you will be using. For instance, a splashscreen and home screen are givens. But you also know you’re going to need some sort of map screen, and some way for the user to enter their wine preferences. You also find out there is more to wine than just red and white. Although you may not know much about wine, it is still your responsibility to “know the business.” You find out there many varieties of reds and whites and start to wonder how you are going to include potentially thousands of wines in your mobile app.
Its incumbent on you as a UX Designer to investigate mobile app design details by fostering a “participatory design environment.” For instance, what if you built the entire UX that only allowed a user to select red and white wines. Your client might lose confidence that the final product would be substandard. The whole point of UX is for the client and you to collaborate through the participatory design environment phase and work out these kinks before the mobile app is committed to code. During this phase, you come to find out that there are not that many types of wines grown in the Columbia River Gorge. You also discover that although there are many vineyards in the region, only the winemakers that are members of their tourism board will be included in the final mobile app. You discover that only about 12 to 15 winemakers are going to be included in the mobile app, and each typically produces 3 to 5 types of wines. That means at most you will only have to include about 45 types of wines in the mobile app.
Now that you know a little more about wine, does it affect the way the mobile app, specifically its navigation, will work? The answer is “yes!” For instance, had you planned for thousands of wines, it might directly affect how the actual mobile app ultimately works. The mobile app would very likely have to prompt its user to type in the variety of wine they like. Asking a user to type anything is rife with potential problems. If the mobile app user is looking for a Gewürztraminer wine, are they going to spell it correctly when prompted to type it in? If they don’t spell it correctly, they won’t find it. If they don’t find it, they will never visit the winemaker’s tasting room, which is the whole point of the mobile app in the first place.
Let’s say that the wine mobile app only deals with two wines; red and white, and the only words the user has to spell correctly are the words “red” and “white.” It would still be a mistake to depend on the mobile app user’s typing. If a user makes a mistake, you get blamed. The problem is that the tourism board envisioned their mobile app users searching for wines by typing them in to some sort of text box, which you already know is a bad idea. Remember, they are not programmers so they do not know what their options are. Part of UX design is to educate your client about options that they are not aware of. For instance, you may suggest a drop-down menu that lists the wines instead of a text box that prompts a user to type in a wine variety.
Now that you’re ready to lay out basic UX screens for the wine app with the tourism board, there is one last thing to consider: code reuse. The app you’re currently working on happens to be about wine, but what other purpose can it serve? The possibilities are endless. Change out the wine tour for an amusement parks tour or national parks tour or university buildings tour and you have whole new mobile apps; all with essentially the same programming. For instance, the wine tour app has image assets (JPEGs and PNGs) that display logos of different wineries. Can you replace those image assets with national park image assets without changing any programming? What about the maps in the wine tour mobile app, can new national park’s maps be switched in without changing code? Keep in mind that the wine tourism board might not be the last client that wants a navigational mobile app. Perhaps you will modify the wine mobile app yourself and deploy it on Google Play or the Apple iTunes Store?