This chapter is from the book
This chapter is from the book
This chapter is from the book
Defining Your Mobile Audience
It is important to clearly identify a primary user and the primary device. As we work in product teams, and concentrate on deadlines and flowcharts and build wireless applications with new technology, it is easy to lose sight of the end customer. Although many wireless engineering teams forget for whom they are making products, they have the ability to liberate the user. A usability specialist or an interaction designer is usually in charge of developing a profile of the end user to help a wireless team recognize the mobile user and individual needs.
It is important to feel that you are building for someone real. Andy Hertzfeld, co-inventor of the original Macintosh Computer, suggests that you build something new for yourself first. Care about your invention and think about improving its purpose to give your life advantage. If you take your work to heart, you might actually start dreaming about it, rather than have a nightmare about avoiding it. Pride comes with making something useful. But you really have to take this observation further; otherwise, you will build something that only an engineer will love. When you move to the goal of building for other people, creating something for a business person or an average citizen, it is important to realize that you are not one of them. You need to set someone else up as the model to use your invention in order to make sure you are not just kidding yourself. This model goes by the name of persona. Let your persona dictate the necessities that will be the mother of invention.
The technology and the mobile audience for wireless applications are very new. They are significantly different from what has come before – for you and everyone on the team. A successful practice that informs developers and qualifies the audience is the identification of the mobile persona. There are three basic steps to studying the mobile user.
Develop a persona.
Describe scenarios.
Create storyboards.
From this work, engineers can build products. Jeff Raskin expresses a working sense for mobile usability when he says, "An interface is humane if it is responsive to human needs and considerate of human frailties2." Wireless interfaces need to be both useful and able to recover quickly from human errors. It takes a special sense to know how to design so that the right wording and the right functions can be used, and so that recovery from their misuse can be graceful.
Personas
As we have said, the mobile user needs to be defined. There is some confusion about the identity of the mobile end user. One of the causes for bewilderment is that the kinds of users differ with respect to the maturity of the technology. The point of the technology adoption curve is that you begin defining your audience generally as hobbyist, business, or consumer by knowing the point in time of your technology. You apply that technology to the appropriate audience. One surefire technique that clarifies the audience and gives you important development tools is the building of a persona.
A persona is a single, concrete characterization of someone who uses an application. There can be three or four of them, but a project always needs at least one primary persona. The creation of persona involves the identification of the typical personality, the writing of a background, a description of characteristics and actions that define the "presence" of the personality, a photograph or illustration of the person, and a "day in the life" of the persona that shows typical activities. This is not a real person, and the picture should be anonymous. It is important that this persona be introduced without explicit reference to your proposed technology. Later in scenario writing, we envision the persona using the wireless technology.
The invention of a "wireless mythology" of a mobile user performing actions is the art of building personas and scenarios. The persona's spirit lives throughout the project. Once a persona is defined, traditional development questions are often resolved by simple reflection and discussion, and answers to the question, "Would Maria (the persona) like this feature?"
An interaction designer is usually in charge of constructing personas. A brief persona description and sample scenarios together guide the wireless project during design and development and are often delivered to a client along with the design deliverables.
A persona is not a real person but a specific characterization of a class of people and their usage patterns for a particular application. A persona must be embodied in a realistic depiction, however. For your wireless application, personas become invocations of the use. They can inspire team members who are often energized by the mascot mythical figure while the project is being developed. This hypothetical mobile user is the result of a merged set of demographic identities for which you build the wireless application. Once constructed by the interaction designer, the persona provides a realistic quality for the wireless team and the client. A persona, although fictional, has a realistic personality. At a minimum, the profile for the persona should have:
Figure 40 "Maria King" persona. (Photograph by Mark Beaulieu.)
){kind=link}
Name: Maria King
Title: Senior Account Executive, Navco Manufacturing
-
Picture: See attached (Figure 40).
Biography: 32 years old, MBA, mother of 2. See attached.
Personality: Likes profession. Reads WSJ. See attached.
Goals: Gain corporate visibility. Improve abilities. Show bottom-line value of all technology.
A short one- or two-paragraph biography for the persona is important. The first paragraph of a persona introduces the person and his or her life, without reference to your technology. It is fair to say that in the early phase of the wireless industry, no one really knows the fundamental qualities of the brand-new technology or what the mobile user wants.
Goals and Tasks
Goals are key elements of personas. Goals spring from the persona's identity. Goals are personal and often embrace professional objectives. Once goals are stated, a design team can help the end user achieve them. It is part of the fun of the mobile design challenge. One look at military wireless mobile goals can be an eye-opener.
Soldiers who use mobile wireless technology have very definite goals. Recently, the U.S. Defense Advanced Research Projects Agency (DARPA) sponsored the development of the Situational Awareness and Information Management System (SAIM). The system feeds wireless battlefield data to soldiers. The program is intended to create an "information bubble" to serve soldiers in action. "On the battlefield, you don't have time to browse," stated Prasanna Mulgaonkar, SRI International lab center director on the project. He stated there are four fundamental issues that a soldier wants to know at all times:
Where are my buddies?
Where am I?
What's going on?
What do I do next?
The litany of mobile battlefield goals of a soldier transcribes to civilian activity. The coordinated needs of a mobile field force often have the same goals. Everyone needs location and direction.
The needs of a person on the go are certainly different from the person sitting at a desk. The early success of the Palm handhelds largely comes from the company's respect for the fundamentally different needs of the mobile user. Therefore, when developing wireless projects, think of the persona as the spirit that builds your application. You write the code, modify content, and deliver the service to this persona. Working for the mobile persona and being in touch with his or her content is how great applications are written.
It is likely that each of your projects will be for a different kind of end user. The personalities change from the experimental technical crowd, to the ordinary business professional, to the liberal early consumer, to the easy-going mass population, to the late-adopting conservative where nothing can go wrong. Development teams that go to the trouble of defining mobile personas often find projects exceed the project's stated goals. The design firm Cooper Interaction Design makes a very strong practice of goal-oriented design. Its site is <http://www.cooper.com>.
Studying Persona
Look forward to starting new wireless projects with one mission. Find the elusive mobile personality in the act of achieving goals. Like a detective, you observe and write down notes about real end users as they complete central tasks. You want to distill the successful qualities of this persona. Tasks can be derived from goals, and are prioritized by them as well. Mobile users are the true clients. A good way to begin is to become familiar with customer demographics. Read users' letters and understand surveys to get an idea of the baseline of the audience. Notice their jargon, their interests, their short-cut notations, their language, their imagery, their concerns, their intent, and their goals. Pay attention to their words and the order in which they do things. Observe their locations, time-sensitive needs, and personal activities. You will see a real difference between building for an installed PC base and building for a new pool of mobile users.
The investigation of the persona often requires interviews. Here are some key questions that are answered in this book: What content interests your audience? How dynamic is this content? Does it require heavy user interaction? You also want to find out when and where they will use the data. Are they at home, at work, traveling for business, or on vacation? You also need to determine the networks that are available geographically. Will the audience remain in a specific area or travel among regions? If they are traveling, what networks are available at home, at the destination, and en route? All these questions were answered for the Nokia mobile user study in chapter 1 in the section "European Wireless Banking."
You want to get a broad feel of the user base to characterize audience by their personas. Understanding identities and personas is key to giving your product personality and purpose. If you do so, your product may not work for everyone, but it certainly will work for these people. You should collect the few key personas you need, but you and your team then need to reduce the collection to one primary and no more than two, possibly three secondary personas. Over time, the persona study will become your jargon, your notation, your language, your imagery, your concerns, and your goals.
Your job is to create a purposeful network application for personas. Once you have identified them, you put into place the simplest mechanisms for the persona to achieve his or her goals. Beyond the generic persona, you can add customization to help end users designate their identities. People signify their personalities with the details of content and you can often take advantage of local time and physical location.
Although it may be fine to think of your end user as a consumer, that is not enough definition to guide your application. You need to come out of the fog of marketing demographics and into the light of a crisp characterization. You may need a skilled writer to help you write a simple narrative. A persona needs enough detail so everyone has a feeling for this person. Turn the average mobile corporate user into Maria King, Field Account Executive for Navco Manufacturing. Her goal is to be visible in her large company and her tasks are to keep its customer banking networks operational and give the best service she can. She covers the San Francisco Bay Area field accounts for the ATM line of her banking products and services. She spends most of her time upgrading network products. She is also mother of two and has a Web phone to keep in touch with the family as well as get updates from the field as schedules change. She cares that her phone is dependable and keeps her in touch reliably. She turns off her phone so as not to be disturbed. Between meetings she checks voice mail, completes decisions with the company messaging system, and sets up her meetings for later in the week.
For vertical market handhelds, your average field professional becomes Bob Hurley, Field Service Technician for Aimless Networks. His goal is to be a productive installer and not work overtime so he can enjoy his family life. He drives a company Ford van six hours a day managing work, taking a regular lunch, and getting back to the family for dinner. He installs six network converters a day and uses his phone sometimes to borrow inventory from nearby drivers. He uses a truck-mounted detachable handheld that has voice. He checks off his installations and when he docks his device, it automatically recharges and updates the dispatch list after every call, alerting him only if a change to schedule takes place.
You will make discoveries as your personas teach you what works and what does not. Users think in terms of the problem that they are trying to solve, and not in terms of how to use the tool to solve the problem. The best tools are transparent to the users. Whenever users have to stop to figure out how to use the tool, they get sidetracked and frustrated, forgetting the problem they are trying to solve. Having an eye out for the customers as they go wireless with your application, you can often observe common patterns of use. With willing users, you can explore with them how best to save time. As much as possible, reduce instrumentality, and cut out what you can. Observe user repetition, what they consider as favorites, and come up with ways to "remember repeated patterns." There are obvious points in software where users should not have to type in information that is well known. Make capsulated "one click" buttons of operations. Streamline steps. If choices get too complex, consider laying them out on a Web site for customer preselection before going mobile. This is a successful strategy of the mobile portals from Oracle or Yahoo!
The Finer Points of Persona Development
Focus groups that look at a project after release often reveal that technology was not being sensitive to real users in the first place. Sometimes focus groups are needed, but try to avoid them. Instead, do your real user focus work up front. Again, before any development, be sure to model users as personas. Two major qualities come to mind in defining your audience – strength of nerve and strength of imagination. It is easy to be overwhelmed when you observe so many mobile users, work with differing client personalities, and are busy developing your team's various technical and creative talents. It takes a lot of energy and inspiration to conduct the development process. Even with great ideas, you have to make hard decisions to be productive. Be bold; have no fear. Conventional wisdom often fails to exploit new technology. It is important to either inculcate creativity yourself or have trusted people on your staff who are tuned into the shape of things to come. Insensitivity to the imagination of your audience is a cause of many lost opportunities.
You should get to know your audience. You may know that you will support active interfaces and construct direct designs. But personal detail is helpful. Begin by reading client demographics, users' letters, and surveys. Understand identities and personas so you can get a feel for the breadth of your solution. Read their jargon, write their notation, use their imagery, and live in their world enough to sense their needs. Meet real users and profile their goals to help characterize the audience as personas. You want to have a real "Maria King" tell you how doing some wireless task truly saves her time. The motivation is not so much to help you figure out an engineering solution, but to put you in a position of continually feeling good about helping people live better lives. In any case, field testing an application and noting actual behavior are great tools for identifying possible usability improvements and alternatives that improve an application. For more information on this subject, see the section "Demographics, Profiles, Personas, Identities" in chapter 21.
Voice Portal Personas
When it comes to developing voice applications, the persona study does not change. However, it is worth noting the points in the persona's life where he or she has time for conversation. Voice portal applications can start as dialogs outlining subject and flow. Later, refinements for natural speech and alternative forms of dialog can be developed. As mentioned, linguists are very useful in the refinement of the project.
Using Professionals as Personas and in Your Project
The ability to rapidly construct meaningful personas and useful scenarios is as important a resource to a wireless project as a good engineer. If you can hire an interaction designer or a design firm, they will save you a fortune in downstream project expenses. Although most of their work is done up front, having an interaction designer and project manager advocate the personas and their needs during the course of development can short-circuit many "misinformed" engineering decisions. Beyond personas is reality. If you do not have an interaction designer for persona creation, because having a full-time person may not be cost effective, it may be useful to contract for this service. Useful examples of persona development appear in chapter 9 of Alan Cooper's book The Inmates Are Running the Asylum3. To help you learn from actual users, quality assurance experts provide excellent end user feedback. Employing seasoned quality assurance professionals early in new technology projects can also be very helpful. Usability experts sometimes apply sophisticated techniques to verify their interfaces, as we discuss in the section "Measuring Interfaces" in chapter 21.
Relevant Content
Personas may want personalization, locality, and time relevance, but they always need a navigation model that makes sense to their world. A multimedia interface designer once designed a kiosk interface that would present a library of fish to fishermen. She came across an idea for a conceptual model by observing her audience. Every fisher knows that fish are drawn to favorite stream locations – fishing holes. She used the fishing hole as a navigational and retrieval model. The kiosk was very popular. Unfortunately, thoughtless models are easier for careless engineers. I am thinking of a wireless traffic-reporting system. A group was given the goal of providing mobile traffic reports to wireless WAP commuters. The engineers simply took the traffic streams and presented the entire list of bulletins for the audience to browse. The engineers did their job and in record time. But this delivered only raw content from a traffic-monitoring agency. The content did not match the world of the driver. Without thought given to organization and relevance, the content will not find its target. Drivers had to repeatedly find what was in their area by accessing bulletins to see if the areas they were traveling through were mentioned. This wireless service was too much work for a driver and had no mobile following. The solution needed a more personal model based on the driver's world. If content is to be valued for being location-based, time-sensitive, and personalized, then how better to find out what this means than by spending time with the people who use it and care about it?
Creating Scenarios
A scenario is a concise description of a persona using technology components to achieve a goal. The scenario considers how the mobile user handles the hardware, how the application is operated, and how the content is used. There are at least two primary types of scenarios to consider: the daily use case and the necessary use case.
Daily Use Case Scenarios
It is important for a team to list all the possible requirements for a product, but the chief focus should always be on the central actions the person is doing with this product most of the time. Functions that are used every day should be handy. Products often make the mistake of providing all the possible functions up front. If many daily operations are used, then design a progressive disclosure of functions. Hide away the sometimes used functions, but put the most used information and functions in a space that is easy to get to. Signify location, time-relevant, and personal needs. Define where and when the application is used. Observe people acting out their data. Europeans have done a stellar job of this. By doing more with less you can see successful WAP and i-mode applications where the user moves from an airport to a taxi to a hotel – checking in, planning an evening, and so on. This solution can involve related wireless companies, for example, those that complete wireless transactions.
What a person does most often in a wireless application should be presented foremost in the interface. Making phone calls or reading email is a common wireless activity. Supporting the most needed functions is a primary design task in building the wireless application. Reading a daily use case scenario, one should easily see the most used functions actually solving the persona's goals.
Necessary Use Case Scenarios
As mobile users need less-common features, you provide them in a place that is not on the main path of choices in the interface. Complexity is best progressively disclosed to the user. For example, reading email is on the main path because it is used every day. Replying to email is on the main path. Composing email is not on the main path. This capability should be a short step away from the main path so it can be found and used when needed. The users should be able to figure out how to do it without external help from other users or manuals.
When composing a scenario, meet real users and profile their goals. Use their language. Learning from this approach means moving around while using actual wireless phones, not simulators.
Creating Storyboards
With the scenarios in hand, and sometimes with a conceptual sketch from the wireless application plan, and an information design outline, an interaction designer can draw a storyboard. A storyboard diagrams the entire story of use, one screen at a time, and shows the display, navigation, and interaction for the wireless device. There are three things to keep in mind: the mobile user conceptual model (process), the display the user sees (output), and the command system through which the user operates the system (input). The screens are laid out in order, with navigational options indicated.
Getting to know your eventual user is the essential beginning of storyboards. It is also worth consulting a wireless architect who can illustrate the general sequence of use for a wireless device and network model that will fit your case. Complex wireless projects have multiple storyboards, but it is best to focus on the storyboard for one primary wireless device. When you get more experience, you can consider the major and minor devices – the primary work going into the PC that has a high screen density and a pointing device and the mobile screens that have low screen density and some standard command buttons. As you will find out, presentation, input, and navigation vary greatly among mobile devices.
Figure 41 shows the storyboard for WAP email application login, including the key navigational Web phone screens. At Lutris Technologies, where this application was made, the storyboard was taken from a high-level site map that outlined the pages that would appear within the WAP email system. Note how attention in this storyboard is spent not on graphics and colors, but on fields and links.
){kind=link}
Tools for creating this storyboard could be PowerPoint™ or Visio™, which let you rapidly lay out the text and graphics of the application. PowerPoint is useful because you can embed fields and links to simulate the application.
Figure 41 Storyboard for WAP E-mail application login (Source: Lutris Technologies, Inc. Reprinted with permission.)
Activity Diagrams with Storyboards
A PC-style storyboard approach is often a problem. Mobile users do not like to navigate hierarchies. They are used to a flow of control. To help advance storyboard design, developers often provide activity diagrams for the mobile user application, as shown in chapter 21, Figure 109 "Activity diagram for a wireless location application."
A wireless system can require two storyboards – one for the mobile field persona and one for a business console persona. The console provides means to administer the account, set up personalization, or prepare content for mobile use. The administrator usually needs only an HTML PC screen. The mobile user clearly needs a storyboard for mobile use. He or she may also need an HTML PC screen to set up mobile preferences.
Of course, there are four wireless mobile families to design for: Web phones, handhelds, pagers, and voice portals. Each needs its own storyboard. Different types of devices sometimes require different types of storyboards to accomodate different features such as screen size, functions, and interfaces. For large projects, each family has variants; for example, a Web phone design is necessary for both WML and i-mode. But the best strategy is to focus on one device and make it work well first. The general navigation can be transposed to other mobile platforms, although there are many fine-grained decisions to make along the way. You must show the primary distinctions of the wireless device on its storyboard.
Web phones can do HTML and handhelds by Palm can do WML, so decisions need to be made up front about appropriate markups and approaches. Ultimately, it is less about the language you use for your device and more about the presentation and input. The plan and the storyboards must be definitive. To reach a truly global audience, you will have to design custom presentations for the families of devices. For an American audience, a PQA is often the best answer, especially if the application is complex and requires a lot of user interaction. For the Europeans, the solutions are more often SMS and WAP.
A handy usability statistic is, the maximum tolerable wait time for a mobile device is one-third of what people will tolerate for a PC. When the user is in motion, responses must come quicker. And a skilled wireless designer will make some decisions to decrease the number of steps. Of course, more steps will be eliminated in testing. Storyboards can go through a round of "paper testing," a practice of quality assurance personnel who take each scene and run it before potential users to evaluate flow and consistency. Storyboards finally go to the engineering team to implement.
Location-Based Scenario
The Wayfinder Scenario (Figure 42) is another example of persona development. Passing through airports, people often have difficulty finding the services they need. The availability of these services, as well as how to get to them, is not obvious. Enter our new persona, Angela, a 31-year-old public relations consultant who is based in Los Angeles, but who has to travel during the week to visit customers. Her goals are always to be on time for client meetings, to travel without hassle, and to not feel stupid. Her scenario is: Angela is on her way to Seattle and has a 30-minute layover in an unfamiliar airport. She wants to grab a cup of coffee before she heads to her connecting flight. The storyboard shows that on her handheld, Angela uses the list screen to look up the service she wants (Figure 42, board 1). After choosing a service, Angela sees the map screen (Figure 42, board 2), and then a close-up of the map (Figure 43). It shows her position, her destination, and major landmarks on the way. She can navigate by looking at the map or by following the simple directions to her destination (Figure 42, board 3).
){kind=link}
){kind=link}
Figure 42 The Wayfinder Scenario (Source: Courtesy of Cooper Interaction Design, Inc.)
Figure 43 Wayfinder close-up of Figure 42, board 2 (Source: Courtesy of Cooper Interaction Design, Inc.)
The Wayfinder's design can be validated against Angela's goals. To meet Angela's goal of getting to her meetings on time, we made the Wayfinder interface simple and quick to use, with only two screens. To help her travel with as little hassle as possible, the Wayfinder includes a complete service database of the airport she is currently visiting, with reliable directions and information. Note the critical role of content to this application. To ensure that Angela never feels lost or confused, the idioms of the Wayfinder interface are familiar, consistent, and easy to use, even in an unfamiliar airport. The Web site for the continuation of this scenario is available at <http://www.cooper.com/concept_projects.htm>.
Using the Wireless Application Plan
If your team is new to wireless development, then a short conceptual sketch showing all the wireless components can help everyone out. This wireless feasibility study is usually made by a wireless architect or an experienced engineer. They know the correct notation and familiar text. The conceptual diagram illustrates the mobile user, wireless devices, wireless networks, a server, and content sources. It shows everyone a first idea of overall use – the flow of the application and the content movement, as well as a sense for the number of devices to acquire for development. General drawings of both the end field use and the administrative operations should be made. The conceptual diagram is brief. The conceptual diagram is not the "day-in-the-life" scenario, but a quick technological explanation of the system. It illustrates general operations and serves as an overview within the wireless architect's wireless application plan.
The wireless architect formalizes all parts of the feasibility study. While the storyboard writer will refer to the study, the wireless architect refers to this diagram and adds the correct layers such as the details of security or synchronization. The architect further illustrates how actions originate and responses are generated. As an alternative to the narrative text in the feasibility study, a timing diagram can show how data moves through the system over time.
When you are starting a wireless project, it is important to understand what you will use. A wireless application plan includes the special qualities of the primary device hardware, the presentation and interactive parts of the software, the specific wireless network, the nature of the data, a solution for how the content is to be used and managed, and the software tools you will use.
The network for the wireless application and its mobile database require construction notes because they must work together. As we will see in the coming chapters, the approach you need to take when developing for a WAN network is considerably different from the approach you take when developing for a LAN network. The wireless network protocols require different efforts to handle data and ensure security. The Web phone handset requires constant connections and has a much more compact interface, providing for greater mobility and lighter content. It deserves a direct and simple interface access. LAN devices are much more like computers, have greater capacity, large screens, and high data exchange rates, and can work offline.
Sometimes with your wireless application plan you can invent wireless applications, at other times you are responding to the market. Regardless, the application must match the maturity of your audience. Recall the technology adoption curve in chapter 2 (Figure 9). Applications historically mature with the declining technical sophistication and increasing service expectation of the audience. An early market application such as a youth portal makes sense. Early vertical market businesses match individuals with directed purposes. The quality of a wireless travel guide suitable for the early-adopting business person is different from that of a consumer variety.
In planning for specialty functions of wireless applications, you must anticipate further tasks. Proximity, location-based service, time-based tracking, notification, and alerting are valuable in a mobile on-your-person device. To get these functions, you may have to produce or buy wireless technology tools. You need to consider not only the wireless application, but also the day-to-day operation for most wireless systems that involve content. Other tools and components required for wireless development that support text messaging, personalization, location, calendars, and other content include servers, gateways, and special engines. They are covered in chapters 18, 19, and 20.
Feedback: The Beginning and the End of Testing
Wireless connections may operate in one city and fail in another. It is best to test in a variety of physical locations. Conditions vary widely in wireless. For instance, you may be able to simulate the loss of a connection between modem and basestation by removing the modem's antenna while it is communicating. Or you could move your application out of your coverage area as you use it.
If you are using middleware that employs a server at a central site, test it under the load of multiple mobile stations as they simultaneously access it. Developers find differences in the ways operators process the signal.
Final validation of a wireless solution means that you must test the solution in the primary use locations. Wherever you expect your primary population to use the application, testing and refinement for deployment are essential. For example, if your wireless application is expected to be used along interstate roads, then make sure the towers are there to support it with the devices you are recommending. Another example is a congested airspace like in New York City or Los Angeles. You may find when you are testing the air that TDMA or CDPD circuits are in fact saturated during the expected peak hours of use. You may need to recommend switching to another data network and set of wireless devices to satisfy local customers. The actual traffic of devices affects the way you optimize your server.
The best Internet developers have made the medium work for them by involving the audience in the solution. Often real users make observations and recommendations about the service. Many changes can be made in short order without costly redistribution. The speed by which a site generating content can reach users who can then respond to it creates a feedback loop, which is unique to the medium of the Internet. This is not merely an editorial loop; it is a service loop, and that can lead to an evolved system. A resourceful development team can quickly post a wireless Internet system and, with skilled design, make changes to improve it while the system is on the air. This means that many a wireless system can be brought up in short order, thereby delivering value to the audience without having to wait the traditional cycle for a full battery of tests to be signed off, delaying market availability and early to market advantages.
As the wireless service becomes maintainable, it is important to provide a feedback mechanism where customers make useful suggestions for the general benefit of the network. You have effectively created a wireless network channel that connects mobile users in such a short feedback loop that response and change are immediate.
Exploiting Mobile Operation
It is very important to have someone assigned to observe the mobile customer periodically during the actual use of the wireless service. This person observes usage, detects unexpected values, and voices evolving goals of the mobile end user. The focus is no longer on planning and building, but on operation. Looking at how editorial, administrative, customer service, or customer support units operate in an organization provides some examples of mechanisms that are necessary for any business to survive and cary on a relationship with its "audience."
This follow-up not only shows you care about the customer, but that your organization is ready to provide industry leadership in what may be a new and legitimate business opportunity. Internet Web sites are able to do this all the time because their business is electronic and easy to change. As you seek to qualify your wireless network, keeping a flexible resource in reserve is key, thus permitting the wireless architecture to grow. The total value cannot always be foreseen.
Although Internet Web sites are able to change in short order, changing navigation and placement on a small wireless device can be very disorienting. This is because mobile applications use a command system that is learned by the mobile user. It is recommended that a pilot audience test system changes before issuing releases.
Innovative companies hold in reserve the resources to grow after deployment. It takes observation and intelligence to recognize how your applications are actually being used. More than once, consumers have been attracted to qualities of an application that had nothing to do with the original engineering plan. The trick is to care about the life of the product and exploit the serviceable value. Your company may let you observe and make changes beyond the initial release. Staying in the loop with the mobile user is the best way.