AWH Almost Ultimate_App_ebook

the ultimate guide to developing an application(on any platform!)

almost^

introduction

Congratulations! You’ve just taken the first step to creating an application that will make life better for your users, your company, and you.

Believe it or not, in a way deciding to create an application is the hardest part of all. That’s not to say that the road ahead will be a cakewalk. You will need to articulate your purpose, not just to yourself, but to the team that will be creating the application. You will have to assemble that team in order to build the product. Then, you will need to find ways of retaining users and ensuring you are consistently meeting their expectations. It is a process.

That’s why we’re here, and why we’ve created this book. After twenty years in software development, we know what it takes to launch a successful application. Whether you are a seasoned pro at leading the creation of a new application or site, or this is your first go-around, we think you will find this ebook helpful.

So, let’s get started…

table of contents

building

thinking 1

preparing

launching

partners 47planning 54requirements 63scope 71usability 78wireframes 85

architecture 93content 100design 107development 113

testing 121deployment 127managing 134retention 141support 147

audience 2awareness 13objectives 21resources 28strategy 38

46

92

120

thinking

1

who will use your application?au

dien

ce

2

Applications live and die by their ability to attract and retain users. It’s as simple as this: you need users to adopt and continue to use your application. Otherwise the time, effort, and resources you put into creating the application will be for naught.

So how do you get people on board—and keep them there? That depends a lot on whether your audience is internal, external, or a cross between the two.

Let’s take a closer look at your potential audience types: Internal usersInternal users are users within your own organization.

External usersThese users are external to your organization and could be customers or future customers.

Hybrid usersThese users are sort of internal and sort of external. Some examples include independent sales reps, partners, or a franchisee.

It all comes down to influence and control.


dien

ce

3

The dividing line between internal, external, and hybrid users isn’t as much about their physical location as it is about how much influence and control you have over them. Obviously, if your users are employees of your organization, you are going to have a much bigger say in whether or not they use your application.

Your influence declines somewhat if you have hybrid users. In many cases, you can request or encourage franchisees, partners, and sales reps do business a certain way, such as by using your new application. But you can’t really make them use it.

If your audience is external, your control fades away. If your external audience is made up of existing customers or prospects, you do have a relationship you can leverage. But if you are going after a brand new audience or customer group, those users have total freedom to take or leave your application.

How your user type impacts your application. Whether your users are internal, external, or a hybrid will have a significant impact on many aspects of the application creation process, including:

Awareness: If you have a captive, internal audience, you can tell them about the new application face-to-face. If you have hybrid users, you can communicate with them directly in a number of ways. Reaching


dien

ce

4

external users is trickier. It will probably involve your marketing or PR team so you can come up with an awareness plan that will resonate with target users.

Price: You probably won’t charge internal or hybrid users anything to use your application. But if your application is external and you will be charging for it, you will need to create a pricing strategy.

Deployment: How will get your application into your user’s hands? Depending on the type of application, you may be able to install it directly to the devices of internal or hybrid users. External users will require a different deployment strategy that might include an app store for a mobile app or finding and subscribing to a web application.

INFLUENCE

The difference between internal, external, and hybrid users is how much influence you have over them.


dien

ce

5

Training and Support: You have more training options with internal users and even hybrid users. Maybe they can be trained in person or via online meetings. For external users, you may have to rely on demos or online training that users engage with on their own. In addition, training for external users often happens during the course of supporting your users.

Retention: Getting and training your users is two-thirds of the equation. The remainder is retaining them. Keeping users engaged varies significantly based on the amount of control you have over them and how easy it is to connect with them. Your retention strategy and activities should be a derivative of your awareness strategy and activities. You will most likely communicate with users to retain them in the same or similar manner as you did to make them aware of the application.

Getting and training your users is two-thirds of the equation. The remainder is retaining them.


dien

ce

6

Closing thoughts.It’s easy to see that user type impacts virtually every aspect of the application creation process. Bottom line? If you want user adoption and retention to go smoothly, take less time and money, and cause fewer headaches, you need to think about who your audience is. Consider how much control and influence you have over them. And most important, create an application users actually want to use and that aligns with users’ needs.

If you want to save time, money, and headaches, make sure you know your audience.

aligning with user expectationsau

dien

ce

7

If you want users to adopt and use your application, you need to make sure your application aligns with their expectations and delivers the value they seek.

The best way to do this? Ask them. Then ask them again. Then ask them yet again.

The point is, whether your target users are internal to your organization or external, it’s critical to have multiple conversations with them throughout the application creation process, and even post-launch. Because the reality is, what users say they want from the application can and will change over time.

Here are some strategies for effectively communicating with your target audience and determining what they really need from the application you are creating.

Keep asking your userswhat they want, becauseit will change over time.


dien

ce

8

Pre-launch user conversations: establishing a starting point. During the thinking and preparing phases of application creation, your conversations with intended users are going to help determine the objective(s) of the application and define preliminary functional and design requirements. These talks are critical because they give you a place to start. But it’s very important to remember that most users have only a limited perspective on what they want at this point, when the application is still just a theory.

For example, users may have an idea of what the application should accomplish or what functionality they will use most. But they likely have not strategically thought through the myriad of options for delivering that functionality and achieving the application’s ultimate objective. They have not considered which options would be best suited to their needs.

What’s more, users can easily be swayed this early in the process. If you present them with alternatives to what they’ve asked for, or if you ask them about their needs in a different way, there’s a good chance their preferences could change.


dien

ce

9

The most important thing to remember is to go back to your users multiple times—especially at key stages in the process, like requirements, wireframes, and design—to ensure you’re staying in alignment with what they want and expect from the application. You may also want to consider providing a group of alpha users with a prototype before you officially launch the application. Giving users something they can play with will go a long way toward validating user requirements.

Post-launch conversations: new needs often arise.Once you have built and launched the initial version of your application, there is a very good chance that users are going to realize something is missing. This simply comes down to the fact that users don’t know what they don’t know. Until they get the application in their hands and start using it, they may not fully realize what they need it to do, or what value the application is, or is not, delivering.

At this point, communicating with your users and making adjustments to the application to meet their needs will be part of process of managing your application and its future versions.


dien

ce

10

Leveraging analytics data: a delicate balancing act.Post-launch, you may have analytics data to consider in addition to what you learn in conversations with users. Be aware that the analytics could be in conflict with what users are saying. It’s your job as the application owner to reconcile the discrepancies between what users are saying, and what they are actually doing.

For example, users may say they don’t value a certain piece of the application. But the analytics show that the piece in question is where users are spending most of their time. This could be a sign of a bottleneck within the application: are users forced to go through a non-valuable part of the application to get to the functionality they really need? By eliminating this bottleneck, you could create a more satisfactory user experience.

Conversely, users may say they value the reporting function of your application. But if they are not actually using it to generate reports, then the application is falling short of its objectives. You will need to troubleshoot the problem and figure out why reporting isn’t being used as intended.


dien

ce

11

Don’t lose sight of your needs. As you work to ensure your application meets users’ needs, it can be easy to lose site of the value you, as the application creator and owner, need to glean from the application. It’s important to remember that your business value is an important piece of the puzzle and must be factored into all decisions about the application.

Closing thoughts.Understanding what users really need from the application isn’t a one-time deal. If you want to establish user buy-in, you need to regularly communicate with users during the process of creating and managing your application. And you need to accept the fact that their needs and wants are likely going to evolve right along with the application. When you acknowledge that this is an inevitable part of the process, you will have a better application creation experience. And ultimately, you will have happier, more engaged application users throughout the lifecycle of your application.

branding your applicationaw

aren

ess

12

Creating awareness of a new application is the same as creating awareness of any other new product. You need to have an awareness plan—or a detailed plan for getting the word out about your application.

But before you think about how you’re going to tell your audience about your application, you need to carefully consider what you’re going to tell them.

More importantly, you need to think about how you want your audience to perceive your application once they hear what you have to say. This comes down to branding. And just like any good product, the best applications have their own well-defined and well-communicated brands.

Getting the experts involved.Branding is a specialized discipline that requires the expertise of marketing, advertising, and/or public relations professionals. If you have a marketing or public relations department in house—great—get them involved as soon as possible. If you don’t have in-house talent, you may want to consider hiring experts who can help brand and promote your application.


aren

ess

13

The purpose of branding. Branding helps position your application in the minds of your audience. It is essentially the summation of the application’s core value proposition—or what makes the application valuable to your business and the end users, as well as what makes it unique or different from other applications on the market. Ultimately, branding dictates what you want your audience to think about when they think about your application.

For example, if you’re creating a new mobile game app, you want your audience to associate your application with fun, entertainment, and an exciting challenge. But if you’re developing a new CRM that’s very intuitive, you want the audience to think about the application as easy, convenient, and time-saving. These descriptors become the attributes or traits of your brand.

Leveraging an established brand.One important decision you need to make is whether or not your application’s brand should be a reflection of your corporate brand. If your business has a well-perceived brand that is associated with a lot of value, you may want to take advantage of that brand equity. On the other hand, you may have strategic reasons for giving your application its own separate identity.


aren

ess

14

Branding elements. Once you and your marketing team have decided on the essence of your application’s brand (i.e. fun, serious, whimsical, simple, etc.) you can apply the brand attributes to key marketing and promotion elements, including:

• The name of your application.

• Messaging—or the main points you want your audience to know about, such as what your application does, how it’s used, and the value it provides.

• Visual identity—or the way the application is represented by iconography or a logo, as well as how the application will look and feel once it’s designed.

As you flesh out the brand, keep in mind that the brand elements need to resonate not only with users, but also with those who make the decision to acquire the application. For example, if you are creating a CRM, your brand messages need to be meaningful to the sales force that will use the application, as well as the national sales manager and the company’s top-level executives who will purchase it.


aren

ess

15

Closing thoughts. It’s important to note that the application’s brand has an impact not just on awareness and promotion, but also on the design and development of the application itself. The brand should be factored into the application’s functional and design requirements and the design of the application’s user interface.

When everything about your application reflects the brand and the core value proposition, you will be in a good position to create a product that delivers on the expectations you set through marketing.

Branding dictates what you want your audience to think about when they think about your application.

promoting your applicationaw

aren

ess

16

How do you make users aware that your application exists?

Contrary to a common misconception, creating applications is no Field of Dreams. No matter how great your application idea is, and even if you have determined beyond a doubt that your application has business value and will meet users’ needs, if you build that application, users are not just going to come.

It’s up to you to ensure users will come. And to do that, you need an awareness plan.

What users need to know.Just like any other product or service, applications require marketing and promotion to drive awareness and adoption. Your awareness plan needs to include strategies for communicating key messages about your application. At a minimum, users need to know:

• What the application is (i.e. mobile app, custom software, web application, kiosk, display, etc.).

• What the application does, and more specifically, what value it provides.

• How the application can be accessed.

• What (if anything) the application costs.


aren

ess

17

Communicating these points is equally important whether you are creating enterprise software for your employees or launching a new mobile app in the App Store. Granted, it’s easier to create awareness if you have a captive internal audience and you know exactly who and where your users are. Nonetheless, every application needs a well-thought-out and well-executed awareness plan.

Get the right people involved. Thinking through your awareness plan starts with bringing the right minds to the table. First and foremost, creating awareness takes marketing and advertising expertise. Leverage your in-house marketing or public relations department, or consider hiring experts who can help.

Your IT team will also play a role in awareness. Specifically, they will be involved in distributing the application. It’s a good idea to get their perspective early on.

For internal applications, you will also want to include your learning and development department, if your organization has one. These individuals will be involved in getting users up to speed with the application and can help promote your application through training.


aren

ess

18

Create buzz.You will want to start generating excitement about your application well before it launches. If your audience is internal, you can give users the scoop face-to-face. You can promote your application on an intranet. Or you can send out teaser emails that tout the value of the application and how it will improve the way users work.

If your audience is external, a good way to create buzz is to promote your soon-to-be application to the media. Be sure to target media who cater to the types of users you want to attract.

Announce the application. When your application is ready to go, you need to let users know how to access it.

For internal audiences:This may involve having your IT department load the application onto computers or mobile devices. You might consider putting an icon on each user’s desktop or homepage. An email to users can also let them know the application is ready while providing details on how and where to access it.

For external users:You will need to break through the advertising noise to get the message about your application heard. As with


aren

ess

19

the promotion of any product or service, an integrated plan that leverages multiple channels is the best way to reach the greatest number of users. A few strategies to consider:

• Advertising & PR: Leverage the power of digital segmenting to target your online consumer and get your ads in front of the websites they frequent or publications they consume. Scour the news and tech publications to learn the stories being discussed. Pitch your application and the solutions it provides within this conversation in order to earn yourself free media from the press.

• Leveraging social media: You can create fan pages for your application on popular social media channels. Facebook allows you to create ads to promote mobile applications. Partner and network with social influencers with large fanbase followings for early demos to get them talking about the application pre-launch.

• Cross-promoting: If you have existing applications, use them to cross-promote your new application. This could be as simple as including a button or tab that will take users to information about your new application.


aren

ess

20

Closing thoughts. Creating an application does not guarantee you any users, even if those users are your own employees! Regardless of your target audience, you need a well-defined awareness plan to tell your users what your application is and why and how to use it. If you build an application, there’s no guarantee users will come. But if you create a strategic awareness plan, then you have a very good shot at getting your application into your users’ hands.

Start generating buzzabout your applicationwell before it launches.

defining a needob

jectives

21

What’s the point? Clearly define the need your application addresses.

Apple’s App Store contains more than a million mobile applications and grows every day. The number of custom software programs, mobile apps, and web applications out there is infinite. Obviously, organizations and individuals are continuously finding reasons to create new applications.

But are those applications really meeting a need?

The successful ones are. The best mobile apps meet users’ needs to accomplish tasks on the go. Or they meet their audience’s need to be entertained. Enterprise software meets employees’ or customers’ needs to accomplish business tasks, often more efficiently than before.

So, what specific needs is your application meeting? If you wrote down and validated your reason for creating an application (as we suggested during the strategy step of the application creation process) then you have a very good place to start defining the needs your unique application or software will address.

defining a needob

jectives

22

Example 1: The need for efficiency. For example, let’s say you are developing software or a web application in order to make the process of recording sales call information more efficient for your sales team. You are probably doing this to meet the sales team’s need to spend less time on paperwork, and more time making sales calls. Ultimately, you’re doing it to meet the company’s need to generate more sales revenue.

To more clearly articulate these needs and define them in greater detail, you will want your sales team, the sales manager, and even the CEO to give input. Then you will be able to put actual numbers or values to the needs.

For example:

• The sales team needs to generate 10% more sales calls per month.

or • The company needs to increase sales revenue by 15% each quarter.

defining a needob

jectives

23

Example 2: The need to compete. Let’s take a look at another example. Perhaps your reason for creating an application is to respond to an application a competitor has released. In this case, your business likely has a need to either keep pace with the competition, or better yet, to one-up or outdo the competition.

In these types of scenarios, meeting your business’ need usually depends on meeting your customers’ needs. So you will want to do a little bit of market research and talk to your customers to learn what your competitor’s application does—and more important, what it doesn’t do, or what customers wish it would do. If your competitor has developed software that lacks key features, then users clearly have a need for a new or improved application. It behooves you to meet this need when developing your software, web application, or mobile app.

Do market research on whatyour competitor’s applicationdoes—and, more importantly,what customers wish it did.

defining a needob

jectives

24

Closing thoughts. By taking the time to clearly define the needs your application will address, you will gain a better understanding of the issues your application’s users face, and what the application can ultimately do for them. And you will be able to define and quantify the real business value of the application. From there, you will be in a great position to map out the specific objectives of your mobile app, web application, or other custom software project.

Make sure that you take the time to clearly define the needs that your application will address.

defining a needob

jectives

25

The most successful applications are typically created to meet specific needs. Once you have defined the need your application will address, your next step is to carefully evaluate the financial impact of meeting that need.

Quantifying the financial value of an application. Let’s say you’re building an enterprise application to boost the efficiency of a specific task for a specific group of employees. To understand the value of the application, you need to know:

• How much time currently is being spent on the task?

• How much time will the application save by creating efficiencies?

• Where will you redirect the time you save?

• What’s the potential dollar value of investing the time you will save on other tasks?

Obviously, these numbers are going to be very specific to your organization and will require input from people with a clear understanding of the costs of operating the business. But once you understand the figures, you can compare the cost of creating the application to the savings your hope to gain from using it, and you

defining a needob

jectives

26

can understand your real return on investment.

As another example, if you are building an application you plan to sell for a profit, you will want to carefully consider what you can realistically expect to charge for the application versus what it’s going to cost you to develop the application. These calculations can help you derive the business value of the project and whether or not it makes sense to move forward.

Considering the non-financial value of your application. Of course, not every application is created primarily to impact the bottom line. Some applications are created for brand-building purposes. Others are created in reaction to a competitor’s application or to satisfy a request from a customer or partner. But even when financial gain is not the driving force behind the application, you should still take the time to carefully consider the financial impact of the application.

In some cases, the cost of creating the application will exceed the financial return you ever hope to gain. Or it may take a long time to recover your investment. That’s okay, as long as you understand the impact up front and you have strategic business reasons that justify the time and expense of creating the application. Ultimately, whatever your reasons for moving forward with an application, you need to be

defining a needob

jectives

27

sure you’re making a sound business decision you can live with.

Closing thoughts. Knowing the real value your application can deliver—whether it’s financial or some other intrinsic value—is critical to your application’s success. It can help you make the business decision to invest the time and energy in creating the application. And down the road, it can help you measure whether or not your application has met or exceeded your business objectives.

!$

Make sure that you understandboth the financial and non-financial

values that your app provides.

forming your teamre

sour

ces

28

Regardless of whether or not Hillary Clinton’s child-rearing philosophy has any merit, we can assure you that it definitely takes a village to create an application. From generating and validating the idea, to building a functionally-sound application, through launching and deployment, a range of people with diverse skill sets will have a hand in ensuring your application’s ultimate success.

The size of your application creation team will vary depending on the type of application you are creating and the size of your organization. In some cases, one person may be able to fill more than one role. But regardless of the type of application, at a minimum, your application creation team should include the input and expertise of the following people:

Strategic Decision MakerYou need someone on your application creation team who understands the business purpose of the application. Depending on the size of your organization, this could be the business owner, a C-suite executive, or a line of business manager. No matter what you call him (or her), this person must vouch for the business value of the application. Throughout the application creation process, he or she must stay involved, at least at a high level, to ensure the application stays in alignment with the overall business strategy and the end users’ needs and

forming your teamre

sour

ces

29

objectives. Learn more about the decision to create an application.

Finance Person In some cases, the finance person may be the strategic decision maker. Or it could be a CFO or controller. Whoever it is, someone needs to evaluate the bottom-line impact of the application. This person will be responsible for analyzing and modeling the costs involved in creating, marketing, and supporting the application; determining a pricing structure for the application (if applicable); and calculating the expected financial return or business value of the application. Too often, the financial analysis role is overlooked with internal applications. But it is equally important whether you plan to use your application internally, sell it for a profit, or launch a new business or line of business around it.

Marketing Person/Team A person or team with advertising, marketing, and/or public relations expertise will need to be involved to help promote and generate awareness for your new application. These people will be responsible for both determining and communicating key messages with your end users, such as what they can gain from the application and when and where they can access the application. Learn more about creating an application awareness plan.

forming your teamre

sour

ces

30

Requirements Gatherer The requirements gatherer considers the needs and objectives of the business and the application’s end users. He or she then defines the functionality of the application in terms of how it will meet those needs and objectives. It’s the requirements gatherer’s job to solicit input from the application creation team and end users as to what the application should do. The requirements gatherer then documents all the functionality that the application should include at launch as well as in future versions. Learn more about defining application requirements.

Designer It’s the designer’s job to determine the visual component of the application, or the user interface—what users will see and experience when they engage with the application. The designer will ensure that the application visually reinforces the company’s brand while supporting the functionality of the application. The designer considers how the appearance of the application impacts the user experience and how it can help support adoption and retention. Learn more about application design.

Application Architect The application architect answers a number of critical technology-related questions about how the

forming your teamre

sour

ces

31

application will operate and perform. This person is responsible for determining the best technology for building the application, where the application will be located, and what types of devices will be used to access the application. He or she helps define security needs for the application, how the application will access and store data, and how it will integrate with other applications and systems. The application architect also weighs in on how to best deliver to the end users. Learn more about application architecture.

DeveloperThe developer or programmer is the person who writes the code that makes your application functional. He or she translates the requirements you specify into a working, secure, and integrated application. The developer will be well-versed in various programming languages and development tools and may play a role in testing, implementing, and possibly supporting your application. It’s a good idea for your developer to have specific experience developing or coding the specific type of application you are creating. In other words, you probably don’t want a developer who specializes only in mobile game apps to develop your enterprise software. Learn more about application development.

Testing and Quality Assurance The person or people responsible for testing and quality assurance will use various testing methods to

forming your teamre

sour

ces

32

ensure that your application meets your expectations. These team members not only test the functionality of your application to ensure it works as intended; they will also look at the user interface and user flow to ensure a quality user experience. Learn more about application testing.

Launch Team The launch team is made of the people who ‘flip the switch’ when it’s time for your application to go live. These people are responsible for the deployment and implementation of the application from a technical perspective. They answer questions such as where the application will reside and how it will be hosted. With a mobile app, the launch team will be responsible for distributing the app to the stores and handling the stores’ review processes. Learn more about application deployment.

Trainer/Training Team If you are creating an internal application or an application for your sales reps, partners, or existing customers, someone will need to be responsible for training the employees, partners, or customers who will ultimately use the application. If your organization has a learning and development department, that department will likely be involved in training. In smaller organizations, the trainers may be IT people or someone else who has an intimate understanding

forming your teamre

sour

ces

33

of how the application functions. With external applications, training is often linked to support and may include developing a demo or online training module that users can access. Learn more about training.

Support Person/TeamWhether your application is internal or external, users will ultimately have questions and need support. Depending on how you choose to provide support (i.e. a help line, email, or online support), you will need a person or people to answer calls, respond to emails, monitor posts, and/or engage in live chat with users. With mobile apps, the support team will also need to review app store ratings and respond to user comments. Learn more about application support.

Closing thoughts. Making sure all the i’s are dotted and t’s are crossed throughout the entire application creation process takes a team of people with a range of talents. You can start assembling your team by evaluating the resources you already have. You may find that many of the talents you require are available within your organization or via your existing partnerships. If not, you will need to search for and hire partners to round out your team. Learn more about selecting the right partners.

assembling your assetsre

sour

ces

34

You need to put together more than the right team of people to create your application. You also need to assemble all the information, data, graphical, and technical elements that will ultimately populate and drive your application.

Some of these items likely already exist. But you may need to do some legwork to hunt them down. Other resources will need to be created from scratch by your internal team or by partners that you hire.

That’s why it’s so important to conduct an inventory and assemble your resources now by conducting a thorough resource or content audit. The process will help you figure out what you have, and what you need to create. And it will ensure all items are ready to go when your application architects, designers, and developers need them.

Here are the types of resources you should consider in your audit, along with some questions to ask to keep your application creation process moving forward:

Branding Resources When it’s time to create the application’s design or user interface, your designers will ask you if you have existing brand guidelines or brand elements, such as logos and iconography, a color palette, and/or preferred fonts and typography.


sour

ces

35

If you do, you will want to make sure you have all the information and the files ready to deliver to your design team. Be sure to ask your designers which formats they prefer. If you don’t, you will need to create the branding elements internally, or you will need to hire designers to create them as part of the project. Be sure to factor this time and effort into your project schedule and budget.

Content Resources All applications contain several types of content. This may include audio and visual content such as sound bytes, photography, and visuals. It also includes text content, such as articles, product and service descriptions, and instructions; as well as items like labels for navigation, buttons, and menus.

Just like branding elements, each type of content either already exists, or will need to be created. For existing content, make sure each item is the file type or format that your designers and developers prefer. For content that must be created, decide whether you have the skills and capacity to create the content in house, or if the work will need to be outsourced to project partners.

Data and Integrations For your application to function, it may need to access


sour

ces

36

certain types of data. You will need to know where that data exists and determine how your application will gain access to it.

For example, will someone need to do data entry? Or will your application integrate with another application to access the data it needs? If so, now is the time to document system dependencies and how you expect them to work. Your application architect and developers can help with the technical details later in the process, but you should put your initial expectations on paper now.

Testing and Development Environments Your developers, whether internal or external, will need a location to develop and test code and to manage the process of developing your application. The development and testing environments might provide everything you need. In other cases, specific development, testing, and release management tools might be used.

You need to decide if you are going to own the testing and development environment, or if you partners will. If you own it, you need to determine how you will give your developers and testers access to the environments.


sour

ces

37

Closing thoughts. Too often, application creators minimize the importance of assembling brand, content, and data resources and establishing a testing and development environment early in the application creation process. They erroneously believe they can quickly and easily gather their assets when they are needed. But be assured, if you don’t take the time now to figure out what assets you have, determine what assets you need to create, and set the stage for development, you can most certainly count on scheduling delays and holdups down the road.

Have you taken inventory of which brand assets you have—and which you need to create?

why do you think you need an app?st

rate

gy

38

Every day, established businesses and entrepreneurs start down the path of application creation for countless different reasons. Perhaps a customer has requested new technology. Maybe a manager or C-suite executive has identified an inefficient process that can be improved through a custom application. Possibly a competitor has launched an application of its own, and now your business needs to respond.

A new application very well may be the right answer in any or all of these scenarios. But not always. Even when creating an application seems like a no-brainer for your business, it’s still important to carefully think through the business strategy behind the application before you jump in. In fact, the question of ‘to build, or not to build’ may be the most critical question you ask during the entire application development process.

Avoiding the dreaded application graveyard. Let’s be honest. Every year, hundreds, if not thousands, of new applications barely see the light of day before ending up in the ever-growing application graveyard. This unenviable fate occurs because too many businesses make impulsive decisions to create applications. Or they invest in the process without doing the due diligence to ensure that the application truly makes sense for their business.


rate

gy

39

So how do you eschew the application graveyard and give your application a long, productive life? By giving the decision to create an application the attention and forethought it deserves.

Questions to ask before investing in a new application:

1. What’s motivating you to create an application? Infinite business issues can drive the creation of custom applications, but they typically have to do with addressing a business challenge or embracing an opportunity. They can run the gamut from creating an enterprise application to improve business processes to creating a software product that can be sold for a profit. Some companies create applications to promote an existing product or service. Some people will create a mobile app simply for its entertainment value. Whatever the reason, it’s important to clearly articulate your unique motivation for creating an application. Then write it down, so you can refer back as you evaluate your application creation decision.

2. Is creating an application the best way to address your business need? Creating a custom application takes time and money. Before investing your resources, consider if creating a new application is the best way to meet the business need you described above. Is there an easier, less expensive, or quicker path to your end goal? Could


rate

gy

40

you buy or leverage an existing application or another technology? Could you generate the results you seek simply by modifying or tweaking an existing business process?

3. Does the application align with your overall business purpose and goals? New applications—just like new products or services—should map back to the bigger picture of your organization. If the application deviates too much from your core business, it may prove too difficult to create or to support down the road. Think about how the application ties in with your larger business objectives.

4. Is your application really strategic—or just reactive? This is an especially important question to ask if you are creating an application primarily in response to a competitive application. Ask yourself if the competitor’s new application truly puts your business at a disadvantage. Are you losing customers or failing to close new deals because of it? Remember, just because your competition has created an application, it does not necessarily mean that the same or a similar application will add value for your business or customers. But if you do decide to go forward, it’s important to take a strategic approach to creating your reactive application.


rate

gy

41

5. How much bang will you get for your buck? This one comes down to the age-old question of ROI. If you invest time, money, and energy in the application creation process, what will be the return? For example, if you are building custom software to drive internal efficiencies, how many people will use the software and how much time and money do you stand to save? Is it really worth the cost of the application creation process?

Closing thoughts. By taking the time to consider these questions up front, you’ll validate your investment in your new application and ensure the best use of your resources. You will set the stage for an application that drives enterprise value. And you will be well prepared to clearly define the specific objectives of your application and the outcomes you expect for both your business and your users.

? ?

Take the time to consider the hard questions up front—what’s motivating you, how will this help your

company, and what is your expected ROI?

strategic or reactive?st

rate

gy

42

Countless applications are created by businesses in reaction to competitors’ actions or to requests from customers or partners. By nature, a ‘reactive’ application is not something that the business has made a strategic decision to create. It may not even be something the company initially wants to create. Rather, it’s something the business feels that it has to create.

Deciding to move forward with a reactive application is not, in and of itself, a poor choice. But it’s important to remember that, even if the decision to create the application is reactive, the process of creating the application can, and should, become strategic.

Here are some tips for turning your reactive application into a strategic endeavor:

1. Make sure the application truly makes sense for your business.If your biggest customer or most important partner demands that you provide an application to continue your relationship, then you probably have a valid reason for creating that application. On the other hand, just because a competitor launched a mobile app does not necessarily mean your business needs to follow suit. It’s your job to think carefully about whether or not creating a new application is the right answer for your business.


rate

gy

43

2. Commit to the process. Even if your organization is not the one who came up with the original idea for the application, once you decide to move forward with it, it’s important to fully embrace the project. If you simply go through the motions, then the end product will probably fall short of everyone’s expectations.

3. Define the application’s value. Building an application that one key stakeholder has asked for does not mean that the application can’t also meet the needs of your business or other stakeholders. If you’re going to invest in the application creation process, it’s well worth your time to consider how the application can provide the greatest value for your business. Even if the application will ultimately serve only the customer or partner who’s asked for it, that customer or partner may not have thought through all the functionality that’s really needed from the application. It’s up to you, as the application creator, to fully explore the application’s potential and to consider how it can best serve your stakeholders and your business.


rate

gy

44

4. Avoid a copycat. If the application is being created in response to a competitor’s application, avoid building just another “me too” application. Take the time to consider how an application will add real value for your business and what your specific audience really needs. Think about not only what the competitor’s application provides, but what it doesn’t provide. If the competitor’s application is missing features or functions that could benefit your users, this is your opportunity to deliver a more robust, more valuable application that will turn the tables and have your competitors reacting to you.

5. Take control of the process. A common mistake businesses make when creating ‘reactive’ applications is to give the customer or partner who requested the application too much control over the process. While you definitely want to consider your stakeholder’s needs and requests, you are ultimately the one creating the application. Take control and ownership of the process and make sure the finished product meets the objectives not only of the stakeholder, but of your business as well.


rate

gy

45

Closing thoughts. Businesses often need to create applications in reaction to a stakeholder’s request or a competitor’s action. But as the application creator, it’s critical to get out of the reactive mode and move into the proactive mode as quickly as possible. When you take a strategic approach to creating a reactive application, and you do your due diligence to think about and prepare for an application that aligns with your business and users’ needs, you are much more likely to create a product that delivers long-lasting value for all parties involved.

Take the time to think how an application fits into your company’s strategic plan.

preparing

46

experience isn’t always expertisepa

rtne

rs

47

The terms ‘experience’ and ‘expertise’ are often used interchangeably. And in a lot of cases, that’s just fine: expertise is very often the direct result of experience in a specific trade or discipline.

However, when it comes to choosing the partners who will help architect, design, and develop your application, there is a subtle, yet powerful, difference between experience and expertise that is important to keep in mind.

What is experience? Experience is the sum of the work that an application architect, designer, developer, or copywriter has performed. Each of these professionals should have portfolios of work that demonstrate their specific experience with different types of applications (i.e. mobile apps, enterprise software, web applications, etc.) for different types of businesses, organizations, or industries.

What is expertise? Based on their experience with different application projects, architects, designers, developers, and copywriters gather knowledge and develop know-how (or expertise) that can be applied to future application creation projects. In general, the more experience a potential partner has with different types of application projects, the greater his or her level of expertise will


rtne

rs

48

be.

Should you look for experience or expertise? For the best results, you need both. If you are creating a mobile app, you will want to work with partners who have experience designing and developing mobile apps, as opposed to partners who have only worked with web applications in the past.

But if you are creating a mobile app for a public library, is it critical to look for architects, designer, developers, and copywriters who have specifically created mobile apps for public libraries before? Not necessarily.

Keep in mind that, as you established during the Thinking section of this site, you are creating a unique application that strategically aligns with your unique business purpose and that meets specific objectives for your unique users. You are not looking for an application that is the same or similar to other applications that already exist.

So even if a potential partner has experience working on an application that’s fundamentally similar to what you are creating, you want to make sure he or she will bring a fresh perspective to your application. If you focus too narrowly on just one type of experience, you could end up with a copycat or ‘me-too’ application that is nothing more than a regurgitation of something


rtne

rs

49

that already exists.

On the other hand, partners with a broad range of experience and a demonstrated ability to create successful applications will likely be better suited to ensure your unique application meets your specific project objectives. These experts will be partners who can help drive the business and user value you want and need from your application project.

Closing thoughts. When it comes to selecting partners to build your application, experience and expertise are both fundamentally important. But don’t make the mistake of looking only for architects, designer, developers, and copywriters who have specific experience creating the same type of application you are building. Your needs will be better served by seeking out partners with overarching expertise in application creation.

Expert Expert Expert Expert

ExpertiseWhen selecting a partner, look for someone with the specific skillset you need, plus a broader subject-matter knowledge to best drive user value.

choosing the best partnerspa

rtne

rs

50

As you know by now, creating an application takes a team of professionals with various types of expertise. If you don’t have all of those talents and capabilities within your organization, or if your internal resources don’t have the bandwidth to handle all aspects of your project, you will need to hire partners.

Whether you are looking for marketing people, application architects, designers, developers, or people to support your application once it’s live, your partners should not only be experts at what they do; they must also be people with whom you can work comfortably and effectively.

Here are some things to consider when selecting the right partners for your project.

Freelance vs. agency/firm. There are plenty of agencies and firms out there that offer turnkey application creation services. There are also plenty of independent or freelance contractors that can handle various aspects of your project. The choice primarily comes down to time, cost, and risk.

If you hire an agency or firm, your costs may be a little higher. But the agency/firm will help manage the project and bring together the various resources needed to create the application from start to finish,


rtne

rs

51

which will decrease the time you need to personally invest in the project. There’s also considerably less risk that your project will fall through the cracks or won’t be completed as promised when you hire an agency or firm, especially a reputable one.

On the other hand, freelance contractors often offer a price break. But since most contractors operate independently without any backup, if something prevents that contractor from completing your project, it could put your timeline at risk. Additionally, if you hire multiple contractors to handle different pieces of the puzzle, you’re going to spend more time coordinating and overseeing your project.

A little bit of this and a little bit of that. You don’t have to go all agency/firm or all freelance. You can hire a company to handle a large chunk of the application creation process, and still hire a contractor or contractors for specific components, such as photography or content development. You could also hire more than one agency or firm, such a firm that excels at graphic design and another that specializes in development. In these types of scenarios, be sure all parties understand their roles in the project and how they need to work together to get the job done.


rtne

rs

52

Location, location, location. These days, technology makes it easy to work virtually or remotely with your project partners. This means you aren’t limited to looking for agencies and freelancers who are located in the same town as you. In fact, for some portions of the project, such as photography, it may benefit you to work with someone who is in close proximity to the types of images you need, rather than a photographer who is close to your office.

Before you choose an out of town agency or contractor, just be sure you and your other key partners are comfortable working virtually. Application creation is a very collaborative process, so you need to be okay collaborating via phone, email, and the Internet, as opposed to face to face, if you hire remote partners.

Avoid culture clashes. Keep in mind that an application creation project takes a considerable amount of time, as well as close collaboration. So it’s important to choose partners that aren’t going to rub you—or your other partners—the wrong way. Carefully consider each potential partner’s work style and culture, including things like adherence to deadlines, how deliverables are presented, ability to work as a team, and ability to take and give feedback. When possible, choose partners with similar values and work style as yours so that everyone can play nice


rtne

rs

53

together.

Closing thoughts.Bringing agencies/firms and contractors together to create an application is kind of like arranging a marriage. For better or for worse, the partners need to be able to work effectively with each other for the long haul. Beyond looking for expertise and specific skill sets, seek out partners that are a good fit in terms of work style and culture. When you factor in these types of considerations, you can look forward to a smoother, more enjoyable application creation experience.

You don’t have to contract exclusively with freelancers or with one agency. Just make sure that culture clashes

won’t prevent a cohesive team dynamic.

major milestonespl

anni

ng

54

Like many major projects, creating an application is a step-by-step process. In fact, this entire guide is designed to describe, in detail, each step of the process and provide you with the information and tools you need along the way. Ultimately, completing these steps moves you toward key project milestones that represent significant accomplishments along the path to a living, breathing application.

Below we define the nine major milestones that you will achieve during your application creation journey.

Milestone 1: Deciding to create an application. At first, simply making the decision to create an application may not seem like much of a milestone. After all, individuals and businesses make this decision all the time—but they don’t always make it strategically. If you engage in the Thinking section of this site, if you take the time to go through the process of evaluating the business purpose behind your application, and if you do your due diligence to consider how the application achieves specific objectives for your users, then you will see how deciding to move forward with your application is indeed your first major milestone.

major milestonespl

anni

ng

55

Milestone 2: Defining requirements. Once you determine that the application you want to create has value for your business and your users, then it’s time to define exactly what you are creating. You must document what the application will do (functional requirements), how it will do it (architectural requirements), and what the user experience will be (design requirements). Your completed requirements documents will clearly establish the footprint of your application and provide developers and designers with the information they need to create the application you are envisioning. Learn more about defining application requirements.

Milestone 3: Wireframes Leveraging your application’s requirements, wireframes map out the functionality and workflow of the application page-by-page or screen-by-screen. The wireframes take the application that you have been theorizing and put it on paper in a blueprint-like format. When you have completed and approved wireframes, you have the skeleton or framework upon which the application can be built. Learn more about wireframing.

Milestone 4: DesignUsing the wireframes, designers will apply color, fonts, graphics, and an imagery style to the pages or screens of your application, bringing the user interface

major milestonespl

anni

ng

56

to life. Typically, design starts with just a few pages of the application—the main page or screen and one or two subpages. Your designer will probably create two or three design paths from which you can choose. Once you select a concept, the designer will apply the design to every page of the application and ultimately finalize the design by inserting the actual content (copy, images, iconography, video, etc.) for your application. Learn more about application design.

Milestone 5: Development This is the part of the application creation process that makes your application do what it does. It includes both front end and back end development. Developers apply the coding and programming that brings the design and user interface (or front end) to life, allowing users to interact with your application. Developers also write the code for the back end, which makes the application functional, scalable, and secure. Learn more about the application development process.

Milestone 6: Testing Once the entire application is developed, it’s ready for testing. You will be able to experience the entire application just as a user would. And you will work with your development and design teams to work out any bugs or glitches with functionality or problems with the user flow or experience. Learn more about application testing.

major milestonespl

anni

ng

57

Milestone 7: ProductionFollowing the testing phase, your application will be moved to the hosting environment where it will ultimately live once it goes live. During this production period, a final round of testing will be completed to ensure the application is ready for users.

Milestone 8: Launch Congratulations! This is really the milestone you have been working toward all along. Per all your plans, your application will go live and be available for users to access.

Milestone 9: Support and Management After your application goes live and has attracted a user base, it will be time to focus on supporting and retaining your users. This process may involve providing training for users or managing releases of future versions of your application. Whatever the case, it’s up to you to ensure your application delivers value to your users and your business for the long haul. Learn more about supporting your application.

Closing thoughts.As is obvious from this ebook, creating an application is a detailed process with many parts and pieces. But if you carefully follow the steps and work toward achieving the key milestones, you will be rewarded

major milestonespl

anni

ng

58

with an application that meets your users’ needs and delivers significant value for your business.

There are nine key milestonesto develoing an app. How manymilestones have you completed?

managing the projectpl

anni

ng

59

What’s the best way to manage an application creation project?

As the creator and eventual owner of a new application, it falls on you to manage the process of creating the application. Of course, many application creators choose to work with turnkey agencies that handle the day-to-day management of the project. However, whether you partner with agencies or freelance contractors, or you leverage internal resources to create, build, and launch your application, you still need to be actively engaged in reviewing work, ensuring deadlines are met, and ultimately bringing the application to fruition.

How to manage what you don’t understand. Just because you’ve been charged with creating an application, or you’ve had a great idea for a new application, doesn’t mean you’re an expert in the various disciplines required to bring that application to life. You may not be a designer, an application architect, or a developer. You may not understand exactly what those professionals do. But that doesn’t mean you can’t manage their work.

What it does mean is that you need to take some time to familiarize yourself with how the members of your project team operate. Find out the key steps in their process, what types of deliverables you can expect,


anni

ng

60

and when you can expect them.

Also, find out what resources the partners need to do their jobs, and when and how those resources should be delivered. For example, does your designer need photographs, logo files, or special fonts? What format should each resource take? Do you need to provide your developer with access to a development and testing environment, or will they provide it?

When you clearly define what your partners need from you, and what you can expect from them, you’ll be in a much better position to successfully manage the process.

Set the tone. As the person heading up the project, your team members and partners will take their cues from you as to the character or culture of the project. For example, if you start meetings on time, run them efficiently, and appear fully engaged, then your team members will hopefully follow suit. But if you appear indifferent or like you don’t take the project seriously, then neither will your team.

Nobody’s saying you need to be a drill sergeant. But you should set reasonable expectations in terms of deadlines, deliverables, and involvement level. And you should set a precedent by doing your part to


anni

ng

61

supply information and resources to your team in a timely fashion and as promised.

This is especially true if you’ve outsourced a large part of the work. Your external partners have less skin in the game than you or your internal team members do. So if you want them to be committed and prioritize your project, then you have to demonstrate that the project is important to you.

Go with your gut. When it comes to project management, there’s a lot to be said for intuition. If you get the sense that a member of your team isn’t 100 percent on board, or that something isn’t quite gelling with your working relationship, or that an excuse for a missed deadline doesn’t ring true, then you’re probably right.

It’s best to address these issues sooner rather than later, before your project gets way off track. In some cases, a simple conversation and clarification of project expectations can resolve the problem. If that doesn’t work, you may need to look for a new resource that’s a better fit for your project team.


anni

ng

62

Closing thoughts. As with most types of initiatives, leading by example is the best course of action with an application creation project. The more engaged you are in the project, and the greater effort you make to get your team the resources they need when they need them, the more likely your team will behave in the same way. Remember, you finish how you start. So get your project off on the right foot by being involved, being accountable, and leading from Day One.

Remember to always lead by example.The more engaged you are from Day One,

the more engaged your team will be throughout your entire project.

understanding application requirementsre

quire

men

ts

63

If you’re like a lot of people new to the application creation process, when you hear the phrase ‘application requirements,’ you probably think about requirements related to what the application allows users to do. These functional requirements are an important part of the story, but they are just one of three levels of unique requirements that must be defined for any type of application.

In addition to functional requirements, applications need architectural requirements and design requirements. All three types of requirements are a direct reflection of the application’s scope. Together, they provide what the application will do, how it will do it, and what the user experience will be.

Functional Requirements Functional requirements define the features of the application, or the operations and activities users can perform on each page or screen. Since many applications begin with requiring users to log in, account and password creation capabilities are very often some of the first functional requirements listed for an application.

From there, the functional requirements will depend entirely on what your application needs to do. For example, let’s say you are developing a mobile app for meal planning. Then the functional requirements might


quire

men

ts

64

include things like:

• The ability to view menu suggestions.• The ability to add recipes to a recipe box.• The ability to create shopping lists.

Sometimes, functional requirements include details on how each function will be accomplished or how the individual functions relate to each other. But this isn’t necessary. What is important is to have a comprehensive list of all of the capabilities or functions the application will perform.

Architectural Requirements Once you define what the application will do, the architectural requirements help explain how the application will do it. In general, the architectural requirements define how the application will operate and how the application’s users will be supported. Specifically, these requirements will establish:

• How the application will be distributed and accessed by users.

• What technologies, frameworks, and infrastructure will be required and used to build and run the application.

• How access to the application will be controlled


quire

men

ts

65

and how users will be authenticated.

• How the application will integrate or communicate with other applications or systems.

• On which types of devices the application will run.

• What browsers and operating systems will be supported.

Design Requirements The third set of application requirements deals with how users will experience the application. Specifically, the design requirements provide direction to help designers create the user interface, or what users will see and experience when they access and use the application. Design requirements can include:

• Branding guidelines that help establish the look and feel of the application.

• The types of content or data that the design must support or accommodate, such as infographics, photos, videos, etc.

• The default orientation (landscape or portrait) for a mobile or tablet application.


quire

men

ts

66

• The need for responsive design—if the design needs to adapt to the type of device being used to access the application (i.e. a smartphone vs. a laptop).

Closing thoughts.Understanding and defining the three different types of application requirements not only gives you a complete picture of your application; it also allows you to accurately describe the application in its entirety to the people who will be designing and developing it. This, in turn, allows your partners to provide accurate time and cost estimates. And it helps ensure that your application creation team will successfully build the application you have been envisioning.

Three Types of Application Requirements

Functional Architectural Design

importance of defining requirementsre

quire

men

ts

67

Defining your application’s functional, design, and architectural requirements—and creating clear, concise, thorough requirements documents—is hands down one of the most critical steps in the application creation process.

Well-defined requirements will:

• Provide a comprehensive guide that allows your build team to create a final product that meshes up with your ideas and expectations for the application. • Allow your architects, designers, and developers to give you accurate cost and time estimates for building your application.

• Minimize scope change—the more time and effort you put into thoroughly understanding your user needs, and reflecting those in your requirements documents, the less likely you will have major changes once production work has begun.

Think it through, one step at a time.So how do you create quality requirements? Once you have a solid idea of what your application will do, you need to break down that functionality into manageable steps. Then you need to carefully think through exactly


quire

men

ts

68

how each of those steps will be accomplished from your user’s perspective.

For example, let’s say you are creating a project management application. Users will need to know when something has changed with one of their projects so they can log into the application and take action. How do you want users to be notified? Should the application send an email notification or a text? If so, will users be able to choose their notification preferences? Will this notification selection option be a button that appears on the first screen of the application? Can users opt out? And so on and so forth, until you have thoroughly exhausted all the facets of how this piece of functionality will work.

You will need to go through this question and answer process with each piece of functionality, and carefully document your answers. You’ll also want to complete this exercise as you think through the user experience (colors, fonts, imagery, types of content, etc.) and the technical aspects of the application (how it will be distributed, how users will be authenticated, how the application will access data, etc.) The result will be well-defined functional, design, and architectural requirements documents.


quire

men

ts

69

Prioritize your requirements. As you think through and document the requirements for your application, you may end up with a long list of features and functions. Remember that no application launches with every single last item on the creator’s wish list. That’s why you will want to prioritize your requirements in terms of which requirements are absolutely necessary for the application to function and to deliver the intended value, and which would just be nice to have. Some of the ‘nice to have’ requirements may need to wait until future versions of your application.

Putting it all together. Requirements documents come in a lot of different varieties, ranging from informal wish lists, to formal, structured documents, to screen mockups or wireframes. At this point, the format doesn’t matter nearly as much as the content. If it’s helpful for you to think through your requirements in a visual manner by sketching out each page, then by all means, write your requirements in a wireframe format.

The important things to remember are:

• Be as detailed as possible. The more direction you give to designers and developers, the more likely they are to create something that matches your vision.


quire

men

ts

70

• Make your requirements clear, concise, and easy to read. Effective communication is key.

• Accept that this is just version 1. Requirements documents are likely going to change as you continue to gather user input as well as input from your designers and developers. And that’s okay. Remember, it’s a lot easier to make changes to requirements when you’re still in the planning process, before actual production work begins.

Closing thoughts. The time and effort you put into creating quality requirements will set the stage for the remainder of the application creation process. If you rush through this process, you will surely run into problems and, quite possibly, costly rework down the road.

Be sure to get a head start on writing solid requirements that will start your build process on the best possible foot.

scope versus requirementssc

ope

71

In the world of application creation, ‘scope’ and ‘requirements’ are a little bit like the infamous chicken and egg: it’s hard to say which comes first, or where one ends and the other begins.

Generally speaking, requirements define what the application does (i.e. what it enables users to accomplish) and how it does it. These requirements are the individual pieces and parts that make up the application. The scope of the application is the sum of all the parts. Put another way, scope is like the wrapper around all of the application’s assets and attributes. The scope of the application must be big enough, broad enough, and deep enough to encompass:

• All the features and functions of the application • The integrations and dependencies with other applications and systems• The size and usage of the intended audience• The delivery and accessibility of the application

Together, all of these attributes or requirements make up the scope of the application.

Which comes first—the scope or the requirements? That’s a good question. And the answer is a little bit of both.


ope

72

During the Thinking stage of the application creation process, you considered the business objectives of your application, who will be using the application, what business’ and users’ needs the application will meet, and what value it will provide. The answers to these questions gave you a general picture of your application and a broad sense of its scope.

Now, during the preparation stage, you will specifically define the application’s requirements, what the application needs to accomplish from a functional perspective, and how it will do so. Based on this information, you will know how broad and complex the application needs to be to accomplish its purpose. And you may need to tweak or modify your initial idea of the application’s scope.

Keeping your application in scope. On the other hand, if you find that your requirements are way outside of your original idea of scope, it may be a sign that your application is beginning to stray from the strategy and objectives you established during the thinking stage. This may be a good time to revisit those strategy documents. Do a gut check, and make sure your application is still headed in the right direction.


ope

73

Closing thoughts. Once you understand your application’s scope, and how requirements impact it, you will be ready to talk with programmers and designers to get an accurate estimate of the time and costs needed to build your application. Remember, once you have defined scope and requirements, it’s a good idea to try to stick with them if possible. After this point, if you add features that change your scope, you will also be changing your budget and timeline, and possibly the purpose and intent of your application. Learn more about what drives scope change.

Be sure to understand your application’sscope before you begin talking with

programmers and designersto start building.

what drives scope change?sc

ope

74

What drives scope change? And how does it impact my project?

In an ideal world, once an application’s scope and requirements have been defined, and you have moved into wireframing, prototyping, and building, no changes will be made to the requirements or scope.

Notice that we said ideal. In reality, this rarely, if ever, is the case.

The fact is, some amount of scope change is going to creep into every application project. It’s simply the nature of the beast. Your job as the application owner is to understand what drives scope change so you can do your best to minimize its impact on your project.

Key culprits of scope change. The number one cause of scope change is the fact that it’s difficult for people to describe everything they want from an application when that application is just a theory. Until users can get their hands on a functioning application (or at least a prototype), they may not realize everything they need the application to do. That’s why determining user needs—and defining the functional and design requirements that will meet those needs—is an ongoing process that may extend beyond your initial launch date. Bottom line? What users want and need from an application evolves over


ope

75

time. And that drives scope change.

Another reason behind scope change is poor resource planning. It’s important not only to gather your brand, content, and data resources well in advance of the application building process, but also to validate the usability of those resources. If you think you have photos ready to go, then you find out during design that the images don’t mesh up with design requirements, you now have a new photography component of the project to fit into the schedule and budget. Or, if your application is dependent on another system for data, and you discover during architecture that the intended integration cannot occur, your integration approach—and, therefore, the scope of the application—will change.

The snowball effect. Scope change is such a sensitive topic because it impacts virtually every aspect of your application, ultimately costing you more time and money. Depending on when the scope change occurs, it can lead to additional work or rework. For example, if the scope change is the result of new requirements, then portions of the user interface that have already been designed and approved may need to go back to the drawing board. Code may need to be rewritten to accommodate modified or new functionality. This, in turn, can impact testing and even plans for


ope

76

deployment and support.

Sooner is better than later. Scope change is less disruptive the earlier in the process that it occurs. Imagine building a house. Making changes to blueprints is much simpler than making changes once the foundation is in place or the walls are up. In the same vein, requirements and scope changes that happen during wireframing and prototyping are easier, faster, and less costly to deal with than scope changes that occur once architecture, design, or development work has begun. Minimizing the damage. It’s important to go into your application creation project with the mindset that scope change can and will occur. However, while some change is inevitable, you can mitigate the impact by following these best practices:

• First, make sure you have a plan in place for talking to users early and often to determine their needs. Keep going back to the user to get their input and to validate your requirements, especially during the planning, wireframing, and prototyping steps.


ope

77

• Go through as many revisions to your requirements documents, wireframes, and design concepts as needed to make sure they are as close to perfect as possible before final design and development begin. Remember, it’s more expensive and time consuming to change code than it is to make changes on paper or screen.

• Be sure to give resource planning the time and attention it deserves. Assemble your application creation team and do your resource audit early in the process to ensure that brand, graphical, content, and data assets are ready to go when you need them.

Closing thoughts.It’s just human nature to want to get through planning as quickly as possible so you can get to the ‘good stuff,’ or the building phase where your application starts to become something you can see and touch. But if you rush critical steps like requirements gathering and wireframing, you can count on contending with costly, time-consuming scope change down the road. Though it’s impossible to entirely eliminate scope change, it is certainly possible to keep changes to a minimum by investing time and effort in the application preparation process.

what is a use case?us

abili

ty

78

A use case—also called a user story or use case scenario—describes the step-by-step process an application user will follow to achieve a specific goal. Use cases build off of the application’s functional requirements. They explain in detail how those requirements are achieved from the user’s perspective.

For example, let’s say you are creating time tracking and expense reporting software. One of your application’s functional requirements may be for supervisors to generate expense reports for employees. For that requirement, the use case scenario may go something like this:

Generate Expense Report • Step 1: Log into the application by entering user name and password.

• Step 2: Click Visit Report Center in the upper left hand corner of the page.

• Step 3: Select the Expense Reports tab.

• Step 4: Enter the employee or employees’ names.

• Step 5: Enter report beginning and end dates.


abili

ty

79

• Step 6: From the drop down menu, choose the types of expenses to be included. • Step 7: Click Generate Report button.

Creating use cases like this for functional requirements or sets of functional requirements ensures that your application ultimately includes the features users need to achieve their goals.

How many use cases should be created? That depends on the scope and complexity of your application and how many different user types your application will support. Generally speaking, you want to create use cases for each specific goal that a specific user wants to achieve.

Building on the example above, let’s say both supervisors and employees will use the time tracking and expense reporting application. That means you have two user types, often called ‘roles’ or ‘actors.’

Both of these actors will be using the application to achieve specific goals. As mentioned, supervisors will use the application to generate expense reports. They may also use the application to review employee timecards and approve vacation requests. So separate use cases should be created for each of these three unique supervisor goals.


abili

ty

80

At the same time, employees will be using the application to enter expenses, record time, and submit vacation. So three additional use cases should be created for employees.

Remember the 80/20 rule. Our use case example outlines a linear, logical path to achieve a goal. But for many applications, the user flow is not quite so sequential. Often, users have the ability to ‘roam around’ in an application and may have infinite paths to achieving one goal.

For these types of applications, documenting every possible use case scenario would not only be time-consuming and exhausting; it wouldn’t generate much return. That’s because of the 80/20 rule that states that 20 percent of potential use cases will likely account for 80 percent of the activity within your application. All of the other use case scenarios are simply not going to be used often enough to justify the time and effort of documenting use cases.

Are use cases always needed?Not always. Some applications have very small functional footprints and only allow users to do one thing in one way. For these applications, the functional requirements document will likely be adequate to describe what users can achieve with the application.


abili

ty

81

Closing thoughts. Use cases are a critical tool in defining the user experience and ensuring that your application gives users the functionality they need to achieve their goals. To create the most effective use cases, put yourself in your user’s shoes. Carefully consider how a typical user will use your application, what functionality he is most likely to leverage, and the primary way he will use that functionality. By focusing on creating use cases for major user activities, you can help ensure that your application will support your primary user base.

Remember the 80/20 Rule:20% of potential use cases will likely account for 80% of the activity within your application.

how is a use case used?us

abili

ty

82

Different members of your application creation team will leverage use cases or user stories throughout the application creation process:

Design and Development.Initially, designers and front-end developers will use the use cases to help shape the user experience. Based on the use cases, designers and developers create and program the features and functions users need to achieve specific goals within the application.

Testing.Once enough of the application has been developed to allow for testing, use cases will once again be leveraged. As this point, use cases act as a sort of checklist that can be used to validate that the application actually allows users to do what you planned for them to do.

For example, assume you are creating a CRM application within which users will enter new contacts. In the use case for this requirement, you spelled out the steps users would need to take to accomplish this objective. Now testers will validate each step in the use case.

• They will make sure there is an ‘Add New Contact’ button.


abili

ty

83

• When this button is clicked, they will validate that the application launches a new contact entry page.

• Within this entry page, they will check that all of the information fields exist and that data can be entered.

• And so on and so forth until each step in the use case has been confirmed.

When the use case and the application don’t mesh. During the testing process, if you find that the application fails to align with the use case at a certain point or points, you can either:

A) Determine that a bug exists within the application and that reprogramming is needed to fix the issue.

or B) Consider revising the use case to match what has been developed.

In the strictest programming environments, any discrepancy between the use case and the application is always treated as a bug or a problem with the application. The problem is recorded on an issue log, and the application will ultimately be changed to match the use case.


abili

ty

84

It’s important to keep in mind, however, that during the course of creating the application, designers and developers may uncover better or more efficient ways for users to achieve a goal than what was originally documented in the use case. When this happens, the use case should be updated to reflect the changes made during the production process.

Training and Support. Once design, development, and testing are complete, and when the use cases and the application are in complete accord, then the use cases can be leveraged for various user support and training activities. This can include developing user training manuals, creating online help modules, or educating the team that will provide user support.

Closing thoughts. Use cases, or user stories, help inform many steps of the application creation process. While they play an important role in ensuring that what’s created aligns with your original objectives for the application, use cases are not set in stone. During actual production work, if designers and developers come up with ideas for improving the user experience, consider adapting your user stories to reflect modifications that will ultimately improve how your application works.

what are wireframes?w

irefr

ames

85

Wireframes represent the transition point between planning for your application and actually building it. Essentially, the wireframes are like a grayscale blueprint of the functional and design components to be included in the application. They leverage the application requirements you defined in the previous step and use them to create the skeleton or framework upon which you will ultimately build the application.

Wireframes can be sketched by hand or created using computer software. Either way, wireframes should show:

• The location of all the functional, design, and content elements to be included on every screen or page of the application, including toolbars, buttons, icons, text, and video boxes.

• The hierarchy, scale, and priority of each of the elements and their relationship to each other.

• The workflow of the application, or how a user can move through the application from beginning to end to accomplish tasks or activities.


irefr

ames

86

What wireframes are not. Wireframes are not design. They don’t show what the components of the application and user interface are actually going to look like.

And therein lies the problem.

The reality is that wireframes are exciting and anticlimactic at the same time. On the one hand, your application starts to take shape on paper for the first time, and you will be excited to see this initial representation of your application. On the other hand, wireframes lack the wow-factor that only color, font, graphics, and imagery can bring. Seeing the black and white abstracts and the placeholder text and images can be a bit of a letdown when you are anxious to see your application come to life.

Why wireframes matter. Lackluster as they may appear, wireframes are arguably one of the most—if not the most—critical milestones in the application creation process.

For one thing, the wireframes will validate your requirements by mapping them out on paper. They show you whether or not the functionality and workflow you’re planning actually make sense.


irefr

ames

87

Even more important, wireframes bring any functional or design gaps to light. Nine times out of ten, people will find one or more ‘holes’ in the wireframes. Identifying and correcting these misses during the wireframing step is much easier and much more cost-effective then making additions, moves, and changes after the actual design and development work begin.

Closing thoughts. Though they are far from glamorous, wireframes are a key step in the application creation process. By understanding what wireframes are and why they are important, you can give them the time and attention they deserve. And by making sure your wireframes are spot on before production work on your application begins, you gain peace of mind that you are investing in the application you want to create. And you can save yourself a lot of time, money, and headaches down the road.

Wireframes, while far from glamorous, can help you connect the dots in your application’s usability—and pinpoint gaps

that you might have missed in the planning stage.

wireframes versus prototypesw

irefr

ames

88

An application prototype—also called a proof of concept or a minimally viable product (MVP)—is the very first functioning iteration of your application, which is used to validate requirements and confirm user value. Essentially, a prototype is a working version of your wireframes. While wireframes map out, on paper, the location of all the functional elements to be included in the application, the prototype brings the roadmap to life, offering a version of the application with real—though limited—functionality.

Why do a prototype?In the past, it was common for application creators to move straight from wireframes into development, surpassing prototypes. But while wireframes give a good sense of what an application enables, they still leave a lot to the imagination.

On the other hand, prototypes can actually be played with and used, giving you a much better sense of how the application works and whether or not the functionality meets your expectations and you users’ needs. When you and your alpha users can get your hands on a prototype and interact with its features, you may notice functionality that’s missing or that needs to be changed.


irefr

ames

89

Remember, it’s much easier and more affordable to make changes or iterations to requirements documents, wireframes, and prototypes than it is to change your application once full development begins. A prototype is like an insurance policy: it gives you confidence that you’re investing in an application users will actually need and want to use.

What should a prototype include? Like wireframes, prototypes are all about the functional aspects of the application—not the design or user experience. What’s more, prototypes should be limited to only the core features or functions of the application. This is important for a number of reasons:

• First, your developers will be doing some coding and development to produce the prototype. Since you may need to make changes or do rework based on user feedback, you want to develop only those features that make the prototype usable, and nothing more.

• Second, you really want alpha users to concentrate on the core features of the application, and to not get distracted by peripheral features. Less really is more at this point—limiting what you offer in the prototype ensures users stay focused on the features that matter most.


irefr

ames

90

Who should use the prototype?You will want to release the prototype to a small group of alpha users. Alpha users should be real users who will ultimately gain value from the application—not just your friends or family. In addition, alpha users should be:

• Well-known, trusted advisors who will give you brutally honest, straightforward feedback.

• Capable of grasping the concept of the application based on preliminary wireframes and prototypes.

• Available and able to commit to the process. You want to work with people who have the time to be engaged with your prototype and who are able to get their feedback to you in a timely fashion.

Deploying your prototype. Once you have selected your alpha users, get your prototype in their hands as cost-effectively as possible. Do not spend time or effort on a well-defined deployment plan at this point. Just get the prototype in your users’ hands. For example, even if you’re creating a mobile app, it may be easiest to deploy it over the web and simply ask alpha users to adjust their browser size to mirror a mobile experience.


irefr

ames

91

Closing thoughts. A prototype is an excellent vehicle for obtaining robust, meaningful feedback about your application’s functionality and ensuring that what your building aligns with user needs. If you put the effort into creating a prototype and selecting alpha users, be sure to take the input you receive at face value. Remember, you selected alpha users because you trust them to tell you what they really think. Don’t filter their comments. Instead, use constructive criticism to tweak requirements and refine your prototype accordingly. If you do, you’ll have a much better shot at ultimately building an application that successfully attracts and retains the users you want.

A prototype is an excellent way to get robust, meaningful feedback about your application—before you’ve fully invested in development.!

building

92

architecture 101ar

chite

ctur

e

93

What is application architecture?

In much the same way that a building architect provides homebuilders with a plan from which to build a home, application architects lay the groundwork upon which application developers build an application’s functionality. Essentially, an application architect implements or executes the architectural requirements for your application and puts the infrastructure in place that enables things like application distribution, security, and integration with other systems.

Who should architect an application? Ideally, someone with specific application architecture experience. In some cases, this could be a developer. But as application architecture is its own distinct discipline, it’s often best to find someone who specializes in architecting applications and systems. A developer may not be aware of all of the ramifications of making specific technology and framework decisions that an architect would understand.

It’s also important to keep in mind the difference between an information architect—or someone who specializes in understanding, organizing, and presenting information and data—and an application architect, or an expert in technology and frameworks. Below we will describe some of the key tasks of the

architecture 101ar

chite

ctur

e

94

application architect. Click here to learn more about information architecture.

What does an application architect do?

Key responsibilities of the application architect include:

Establishing the technology framework.Application architects make the technology decisions on which the application will be developed and that determine how the application will integrate with other applications. The application architect also determines how the application will process information, data, and all content in general. Often, the architect may put in place any databases that will house information that the application will access. The architect configures the relationships between the databases based upon the data processing needs of the application. Defining the integration approach.If the application integrates or talks with other systems or applications, it’s the application architect’s job to establish the manner in which integration, communication, and/or exchange of data will be enabled.

Determining the analytics approach. If the application will include an analytics component,

architecture 101ar

chite

ctur

e

95

then the application architect should ideally be the one to put the analytics framework into place. The architect considers how technology decisions impact analytics options and vice versa.

Depending on the priority placed on analytics, the architect will establish the analytics framework in one of three ways:

1. Create custom code. Analytics capabilities are built into the application’s functionality.

2. Leverage an analytics service, such as Google Analytics.

3. Embed an analytics tool into the application. Instead of writing custom analytics code, companies can leverage off-the-shelf tools to provide the analytics functionality they need.

architecture 101ar

chite

ctur

e

96

Closing thoughts. Application architecture decisions have a direct impact on the application’s ability to perform as required. They also impact the ability for an application to scale and be sustainable over a long period of time. If an application is not well architected, problems will likely rear their ugly heads sooner rather than later, and the application will have a short shelf life before its foundation cracks and major rework is required. On the other hand, if you invest in application architecture early in the build process, your application is much more likely to function as it should and to support your business objectives for the long term.

By investing early in an application architect, you give your application a better chance of functioning as it should and fulfilling your goals.

what is information architecture?ar

chite

ctur

e

97

Information architecture, or IA, is a branch of application architecture that deals specifically with the information or data that an application processes, as well as the information or data that the application ultimately produces and delivers to users. As a result, information architecture has a direct impact on both the functionality and back-end development of the application, as well as the front-end development, design, and user experience.

Let’s take a closer look at both sides of the information architecture coin.

Data handling or processing. It’s the information architect’s job to thoroughly understand all the facets and attributes of the information or data that an application needs to access in order to support its intended functionality. For example, if an application is supposed to perform a calculation, information architecture establishes:

• The type and volume of data needed to perform that calculation.

• If the data is provided by another application or source, where that data exists.

• OR If the data is provided by the user, the


chite

ctur

e

98

attributes of the data and how the user will provide it.

• How the application will access the data.

• How often the application will need to access the data.

• How the calculation will be performed.

In addition, the information architect is responsible for understanding and documenting the relationships and dependencies between the various types of data the application handles. So if one piece of data is driven by (or dependent upon) another, or if different types of data are related to (but not dependent upon) each other, the information architect diagrams and illustrates the various connections.

This information is then passed on to the back-end developers, who write the code that enables the application to perform its intended functions.

Distributing data or information to users. Information architects are concerned not only with how data is processed, but also with how it is ultimately distributed to or communicated to users via the user interface.


chite

ctur

e

99

Going back to the example above, if an application performs a certain type of calculation, the information architect helps shape how the results of the calculation are delivered and presented to the end user. For example, will the calculation result in a 3-digit figure, or a 10-digit figure? Information architects work with application designers and front-end developers to ensure that the application’s design and user interface can accommodate, present, and display the information in the best possible way, so that it is easy to use and understand.

Closing thoughts. In a perfect world, information architecture is its own separate step in the application creation process, overseen by a dedicated information architect. In reality, timelines and budgets often prevent this from occurring, and information architecture is handled in conjunction with overall application architecture, or as part of functional requirements gathering or wireframing. In any case, the important thing to remember is to give time and consideration to the types of data your application needs to function and the types of information it will produce. Doing so will help ensure a higher quality application and a better user experience.

what is content?co

nten

t

100

Many people make the mistake of thinking they don’t need to concern themselves with content because the application they are creating is not content-heavy. True, applications like CRMs and ERPs are not traditionally loaded with 600-word blog posts or page after page of copy. But they still have content. And because they contain only a little, that content needs to be spot-on.

That said, before you classify your application as content-rich or content-light, it’s important to understand what content actually is. We define content as any information that users will see, hear, and/or consume as they use an application. Even if that’s just navigation labels or icons on buttons, it’s content. And it matters to your users and the experience they will have with your application.

Types of content. Content comes in two basic types: audio/visual and text. Let’s take a closer look at each.

Audio/Visual Content Audio/visual content is content that a user hears or sees as part of using the application. It can include:

Sound bites Music clips Images Photographs

what is content?co

nten

t

101

Icons InfographicsLogos Videos

This type of content is not only informative; it makes your application visually interesting and provides opportunities to truly engage users. Creating this type of content typically requires the help of experts, such as photographers, videographers, and graphic designers.

Text Content Text content includes any written words that appear in your application. Text content can either be ‘infrastructure’ content, which basically serves to guide users through your application, or ‘true’ content that is intended to inform, teach, or entertain users.

True content includes:

Articles PostsProduct or service descriptions

Instructions or directions

Privacy policies Any other written information that users access via your application

what is content?co

nten

t

102

Infrastructure content includes things like:

Navigation labels Menu labelsPage numbers Field names

While not all applications have audio/visual content or ‘true’ text content, every application has ‘infrastructure’ content. These labels and headers may just be one or two words, but the words you choose are critical to the user experience—especially if they serve as the majority of the content on your site. Infrastructure content directs the user where to go in the application and provides insight on what the user should do. So be sure to give these words careful thought and consideration—it will make a difference in whether or not users have a positive experience with your application.

Closing thoughts. The types of content your application includes will ultimately depend on the kind of application you are building. But even in content-light applications, content has a major impact on the user experience. If you want your application to succeed, make sure you factor in enough time to determine what content you need and to create compelling content as part of your application creation process.

what content do i need?co

nten

t

103

The type of content you need for your application depends entirely on the type of application you are creating. If you are creating a CRM or ERP, you may only need infrastructure content such as navigation labels, form titles, and field names. But if you are creating a mobile menu-planning app, you will also need to bring in true content such as photographs, recipes, sample menu plans, video cooking demonstrations, and more.

So where do you start? The following steps will help you determine—and obtain—content that will make your application a success.

1. Do a content inventory. Regardless of the type of application, it’s a good idea to create a content inventory, or a comprehensive list of the visual, audio, and text content you need for each page or screen. Be sure to include items such as logos, icons, and labels for buttons—these count as content, too. Click here for more about application content.

If you have completed wireframes, you’ve already done much of the content inventory work. The wireframes show the different content on each page. Using the wireframes as your guide, list out all of the content items in a spreadsheet, and use it to keep track of your content during the application project.


nten

t

104

2. Use what you’ve got. There’s a good chance you already have at least some content for your application. You may have photos, logos, or even videos. You may even have some text content, such as articles or posts.

Carefully review these content assets, and get advice from experts who can tell you if the content is actually usable. You’ll want to make sure images, logos, and other assets are the right style, format, and size for your application.

Note existing content on your content inventory spreadsheet, and be sure to list the location of these assets so you can find them when you need them.

3. Create what you need.Obviously, any content that doesn’t exist will need to be created. And unless you are a photographer/videographer/copywriter/designer all rolled into one, you’ll need to work with the appropriate professionals to generate new content.

Even if you only need navigation and button labels, it’s a good idea to get help. For this type of content, input from an information architect can go a long way in creating an application that’s intuitive and easy to use.


nten

t

105

4. Get in alignment. Whether you are using existing content or creating new content, the content on each screen—and throughout the entire application—needs to mesh up. In other words, what you are saying in text needs to ‘go with’ what you are showing visually. If it doesn’t, the user experience will suffer and users may go elsewhere. Working with professionals can help ensure thatyour content meets your users’ needs and is delivered in a consistent and engaging way.

5. Don’t wait to get started. If there’s one thing that always holds up the project timeline, it’s waiting on content. Design, development, and even testing may be complete, but you can’t go live because content still needs to be created. To avoid this pitfall, get your professional partners hired and get started on content as soon as you know what you need. That way, your content will be ready to go when you are.


nten

t

106

Closing thoughts. Failing to generate quality content can cause an otherwise great application to fall short of your users’ expectations—and yours. Prioritize your content. Give the content inventory, content audit, and content creation steps the time and attention they deserve. And get professionals to be a part of the process. When you do, you’ll be well prepared to create content that your users need and your application deserves.

Prioritize content. Conduct an inventory of what you have and a list of what you

need, and make sure that it all stays consistent with users’ expectations.

creating your app’s aestheticde

sign

107

Design is often the most exciting step in the application building process. It’s the step with which most people can truly relate. While few have the expertise or the even the desire to review pages of code or to debate application architecture decisions, everyone uses applications. And we all have opinions and preferences for what an application should look like and what the user experience should be.

So even if you are not a designer by trade, you should be involved in the process of designing your application. Typically, the visual aspect of your application is created in steps or phases, and you will be asked to weigh in on or approve each step.

Step 1: Concept DesignGoing from black and white wireframes to full color design is a big transition. Designers will apply a color palette, visual tone, fonts, graphics, imagery style, and any other branding elements you specify to your application for the first time. It’s exciting! But because design is so subjective and there are so many elements to consider, it can be a bit of stumbling block, too.

That’s why designers start with just a few pages of the application. This gives you a sense of the design and ensures it is going in the right direction before


sign

108

the design team designs the entire user interface. In most cases, concept designs include the application’s main page along with one or two other high-priority or heavily used pages. You will have a say in which wireframe pages will be concept-designed.

Your designer will probably give you a few different design directions, or concepts, from which to choose. You will be invited to give feedback on the concepts. Remember that your designer is trying to interpret a vision that, at this point, exists only in your head. Getting on the same page is a process. You will need to work together to select the design concept that provides the most user value and best user experience.

Step 2: Detail Design Working with your approved design concept, the designer will apply the selected design direction to every page of the application, fully fleshing out the application’s visual identity and user interface. You get a sense of the entire user experience as a user moves through the application screen by screen.

You will once again be asked to review the design and give feedback. Your changes will be applied to the final design.


sign

109

Step 3: Final DesignFinal design is the buffing and polishing of the application’s design. Ideally, final design will include all final content (copy, photography, iconography, videos, etc.) But in reality, this isn’t always possible because some of the elements may have yet to be created. In this case, content should be as representative as possible of the final content to be included in your application.

Once you approve the final design, it will be handed off to your developers to program the user interface for your application.

Closing thoughts.Application design is a lot of fun. At the same time, it’s serious work. Over the past several years, the importance of application design and user interface has grown exponentially, and user interface has become a key determinate in whether or not users will actually adopt and use your application. As external applications compete for users in app stores, and as internal applications attempt to retain users to drive business value, it has become critical to make smart design decisions and to create a user interface that’s both enjoyable and intuitive. If you don’t, your users will likely look for a different application that does.

what if i don’t have brand assets?de

sign

110

When you begin working with your application design partners, one of the first questions they will likely ask you is what brand and design assets you have. The designers will be looking for assets such as brand guidelines, color palettes, logos, typography, iconography, videos, and photography that they can leverage to design your application.

Large companies with well-defined brands and previous experience with digital media may have these assets in place and ready to go. But often, this question is met with a deer-in-the-headlights look because this aspect of the project has simply yet to be considered. In other cases, companies may have assets—but those assets might not be appropriate, applicable, or ideal for a digital application.

In both scenarios, it’s natural to feel like the project has hit a roadblock. But the good news is, moving forward simply requires the right partners and a few additional steps in the process.

What if I have limited brand or design assets? When you’re planning for your application, it’s always a good idea to consider what resources you have, and what resources you will need. If you find yourself lacking the visual elements necessary to create a quality user interface and experience, then you will either need to create those assets internally, or


sign

111

choose partners with branding, design, photography, videography, or other expertise to help you develop them.

In some cases, if you just need photographs or videos that will work in your application, you can have these assets created as part of the overall application creation project. On the other hand, if you have not yet considered the overall brand for your application, it might be a good idea to launch a separate application branding exercise. In either case, it’s important to factor these steps into your project timeline and budget.

What if the assets I have are not digitally appropriate? Typically, the larger the company, the more likely it is to have a well-established brand and design assets. However, some companies may have a strong brand that comes through brilliantly in physical locations or in print-based media. But if these companies are traditionally non-digital—like many restaurants, manufacturers, or hospitality businesses—those brand assets might not translate well in a digital environment.

If this is the case for you, it doesn’t mean your existing brand guidelines, brand book, and design elements aren’t usable. It simply means that your assets may need to be rethought, repurposed, or reformatted to


sign

112

help create a strong digital presence.

Again, investing time and effort to brand your application and working closely with your internal marketing team or external marketing or branding partners is a great way to ensure that your application’s brand will be reflected in a quality design and user experience.

Closing thoughts. The realization that you need to either create or repurpose brand and design assets for your application is often a stumbling block in the application creation process. But it doesn’t have to derail your project. To ensure the success of your application, be sure to factor branding and the creation of visual resources into your project schedule. By working with the right experts and partners, you can successfully create or evolve a visual brand that shines in a digital environment.

front-end versus back-end developmentde

velo

pmen

t

113

If you think of your application like a car, the back-end is the engine and transmission. You don’t see these components or experience them directly, but they make the car go. The front-end includes things like the dashboard gauges, the information center, and the other user controls. These are the features and functionality you interact with to operate the car. Both the front-end and the back-end need to function correctly in order for you to use the car for its intended purpose and to enjoy the experience of driving it.

Just like a car, both the front-end and the back-end of your application are critical to its ultimate success. Both need to be developed so they operate as intended.

But developing each takes a different set of skills, a unique programming mindset, and most likely, different programming technologies and languages. That is why you will probably work with at least two different developers—a front-end developer and a back-end developer. Sometimes, one developer will have the skills to both pieces. But in most cases, developers specialize in one discipline or the other.

Let’s take a closer look at what front-end and back-end development entail.


velo

pmen

t

114

Front-end development. The front-end of your application is what users see and interact with on the screen. Front-end development is the development or implementation of the application’s visual design or user interface.

Leveraging wireframes and final design, front-end developers write the code that brings the design to life on the screen and dictates how users will interact with the application’s user interface and functional features. For example, if there is a button the user needs to click, the front-end developers ensure that the button functions as desired.

While front-end developers obviously need to know programming languages and the technical aspects of development, they also need to have a keen understanding of the user experience and a good sense of design. It’s ultimately up to them to ensure that the design is reflected in what is made available to users.

Understanding back-end development. Basically, the back-end of your application is everything behind the scenes that users never see or experience directly, but that makes the application run. The back-end runs the front-end and enables the application to process data, so users can perform the actions they need in the application.


velo

pmen

t

115

Strictly speaking, back-end developers don’t even need to know what the front-end of the application is going to look like. They build off the application’s architecture to program databases, integrations, processes, and the like that are needed to house, process, and access information.

Back-end developers do the coding that makes the application secure, robust, scalable, and responsive to user interactions. So when the user clicks the button on the screen, the application processes data entered, then quickly and securely generates the information the user is seeking and displays the next page or screen.

Closing thoughts. Front-end developers and back-end developers are likely to disagree on which part of your application is more critical. Front-end developers will tell you the user interface is everything. And it is! Back-end developers say the user interface couldn’t even exist without the back-end. And it couldn’t! Bottom line? You need both types of development—and most likely two different developers—to ensure your application’s success.

which development approach should i use?de

velo

pmen

t

116

You have numerous options when it comes to the development approach for your application. A development approach has two primary facets: the development methodology and the development language.

In some cases, you (or your developers) may have preconceived notions, preferences, or opinions about which methodology and/or language to use. These ideas typically stem from past experience or expertise and may, in fact, be well-suited to the application you are currently developing.

But you don’t want to fall into the trap of letting a bias for a specific methodology or language drive the application creation. Rather, the application’s unique scope and requirements should dictate and guide your development approach decisions.

Choosing a development methodology for your application. An application development methodology is a framework that governs the process of application development or creation. These methodologies come in two basic flavors—waterfall and agile—with many variations of each.

Essentially, the waterfall approach calls for your developers to develop the application based on


velo

pmen

t

117

written requirements and other documentation. The completed application is then presented to you all at once. Conversely, the agile methodology calls for developers to work collaboratively with the application owner and other members of the team to develop the application in iterations. Agile methodology includes regular, frequent touchbases to ensure development is on track and to plan the next iteration.

The agile methodology often works best with applications that are smaller in scope and with application owners who have the time and resources to be actively engaged throughout the entire development process. On the other hand, if your application is very large and will take years to develop, or if you don’t have time to be involved on an ongoing basis, a waterfall approach may be the better choice.

You may also be able to workout a hybrid approach with your development team. A hybrid approach does not require the same level of involvement and collaboration as agile methodology, but it allows you to see and comment on the progress of development at key milestones, rather than waiting until the entire application has been created, as you would with a strict waterfall approach.


velo

pmen

t

118

Choosing a development language for your application. Once you decide on a development methodology, the other side of the development approach coin is the development langue or programming language. There are nearly as many programming languages in existence as there are human languages. So needless to say, you have a plethora of options.

However, specific programming languages are typically suited to specific types of applications or specific types of functionality. For example, iPhone apps are often written in Objective-C. Java and JavaScript are typically good choices for web applications. You and/or your developer can narrow the field by considering those languages that are most commonly used for the type of application you are creating.

Unfortunately, all too often, familiarity or experience with a specific development language drives the choice of langue for a new application. For example, if your website is written in PHP, you may want to write your application in the same language because that’s what you know. Or if you work with a developer who writes code primarily in C#, then she may automatically recommend that for your application.


velo

pmen

t

119

The problem is, just because a language is familiar doesn’t mean it’s best for supporting your application. Your choice of development language should be influenced by the various aspects and attributes of your application, such as specific functionality, the number of application users and you are expecting, and where the application will be deployed. If you let the application itself dictate the development language—and not your personal bias—you have a much better chance of creating a sustainable application that will perform well in its environment.

Closing thoughts. In many cases, application creators and are not developers and they don’t have knowledge of, or experience with, development methodologies or development languages. That’s why it’s so important to select development partners with experience and expertise you can trust. But regardless of whether you’re following a developer’s recommendations, or making the development approach choices yourself, be sure to ask why a specific approach is being suggested. You want to make sure that the language and methodology are valid options based on your specific application, and not just your developer’s personal preferences. Otherwise, you could end up trying to force a square peg into a round hole.

launching

120

different types of application testingtesting

121

Application testing can take on a wide range of formats and be called many different things. Often times, it’s referred to as alpha, beta, and production testing—but these are actually release phases, not tests. Here, we refer to the three main types of application testing as architectural testing, functional testing, and design/user interface testing.

Let’s look more closely at each.

Architectural Testing Architectural testing validates the development for the back-end of your application. It is typically performed as an automated process that simulates user load to test the application’s responsiveness, scalability, and bandwidth under various user conditions. Essentially, this testing tries to find the application’s breaking point, or the point at which the application will start to degrade due to too many users trying to do too many things at once. The goal is to ensure your application will support all of your users and the ways in which they will use your application.

Functional Testing Functional testing can be an automated or manual process of validating development and ensuring that your application functions the way it’s supposed to function. Each piece of functionality—such as a button


122

that launches a new page, a video, or a calculation—is put through its paces, so to speak, to ensure it works as intended. The use cases created earlier in the application creation process often guide the functional testing.

In general, functional testing can uncover two types of issues:

1. Either the piece of functionality doesn’t work (i.e. the button can’t be clicked or the video won’t play).

2. Or the function works, but the information, data, or content displayed as a result is incorrect or presented in the wrong way (i.e. the calculation occurs, but the answer is wrong). This second type of issue is often referred to as information, data, and content testing; but it is part and parcel of functional testing.

Design/User Interface Testing As application design and the user interface become increasingly critical to attracting and retaining users, testing the design and user interface is also becoming more important. This testing process ensures that the time and effort you invested in creating an effective, engaging user interface have not been lost in the development process. Specifically, design and UI


123

testing looks at typography, colors, sizes, hierarchy, pixels, image resolution, and other design elements to validate that the user interface is presented in the way it was designed.

Unlike functional and architectural testing, design and UI testing can’t be automated, which makes it one of the most time consuming testing processes. In a perfect world, every screen of an application should be tested against the design. But in reality, most people and business don’t have the time, budget, or stomach to test hundreds of screens. At a minimum, you should conduct design and user interface testing on each unique screen type that exists within your application.

Closing thoughts.Architectural testing, functional testing, and design/user interface testing are all important components of the application testing process. If you neglect any of the tests, you risk launching your application with problems that may end up costing you users. Make sure your investment in application architecture, development, and design pays off by running a complete set of application tests and learning your roles and responsibilities in the application testing processes.

what is my role in testing?te

stin

g

124

As the owner of an application, your most important role in testing is to ensure it gets the time and attention it deserves. These days, every product gets some level of testing. Ever seen one of those “Inspected by” tags? So if you’re wondering whether or not you should take the time and make the effort to test your application, the answer is, resoundingly, YES.

The bottom line is, no matter how skilled your application developers are, there’s no such thing as a perfect application or a perfect application production process. There will be issues. Application testing shines a light on the imperfections. And it gives you a chance to correct problems before your users discover them.

Deciding when to test. Once you’ve made the decision to test, you need to decide when to test. Within the application creation world, there’s a lot of debate about the best time to do this. Some say testing should be done in conjunction with the development. This test-as-you-go methodology helps identify problems when they arise so they can be corrected before they lead to bigger problems down the road.

However, even if you test pieces of the application as they are developed, you will still need to test the entire


stin

g

125

application as a whole once development is complete. You may know that individual pieces of functionality work on their own. But you need to be sure all components of the application work together.

If possible, test your entire application before you release it to any users. Even if your first release is a ‘test release’ to a very small group of users, you want to be sure your application works so users can give feedback on actual features and functionality.

Get an objective opinion. Think of testing an application as the equivalent of editing a book. The person who wrote the book should not be the same person who edits it. Same holds true for application testing.

If at all possible, your testing team should be made up of people other than those who actually architected, developed, and designed the application. This ensures an impartial, objective approach to testing and allows the testing team to approach the application as users would—without preconceived notions of how everything should look and work. This gives you more accurate and dependable testing results.

Understand testing results. When testing is complete, you will receive a list of any problems with the application’s architecture,


stin

g

126

functionality, and/or design and user interface. For each issue, the testing results will indicate if the issue impacts your users’ ability to use the application.

It’s up to you to review and understand the test results and ultimately to hold your design and development teams accountable for any high-priority user issues revealed by the tests. Do not just accept these problems or allow band-aids to be applied. The application should be re-architected, redeveloped, or redesigned as needed to properly resolve problems with the application’s architecture, functionality, and design.

Closing thoughts.To ensure your application’s success, it needs to be tested. Preferably before it gets into users hands. And even more important, by people other than the people who did the actual application architecture, development, and design. When you take ownership of the testing process and prioritize testing as a critical step in the application creation process, you are much more likely to deliver user value and realize your business objectives once your application goes live.

understanding deployment optionsde

ploy

men

t

127

Deployment is the process of getting your application into the hands of users. It is the decision on how and where you will provide access to the application. At first, this may sound simple. But you do have various deployment options, and the best deployment strategy for your application depends on a number of factors.

Here are some things to consider before deciding on a deployment strategy:

What type of application are you creating? The type of application—and the type of device on which it will run—has a big impact on your deployment decision. For example, if you are creating a mobile application for smartphones or tablets, you will likely want to distribute the application via an app store, such as the Apple App Store, Google Play, or Amazon Appstore. Desktop applications can also be distributed in app stores or via other websites. Or they can be packaged and sold in brick and mortar stores. Ultimately, once a user purchases a mobile or desktop application (or gets it for free), the application will be loaded onto a local device like a computer, phone, or tablet.

Web applications can also be distributed via app stores, like Google Chrome Web Store, which caters specifically to web apps. Or they can be made


ploy

men

t

128

available at other online locations. However, unlike desktop and mobile applications, web applications don’t run on a local device. Instead, they are hosted by a web hosting provider or a cloud hosting provider, and that makes hosting a critical part of the deployment decision. Click here to learn more about your hosting options.

Are your users internal or external? User type impacts your deployment strategy as much as application type. Users can be internal to your organization (employees), or external (customers, prospects, the general public).

Applications intended for external audiences or meant for public consumption are typically distributed in generally available, well-known locations. This includes retail stores, app stores, and other online locations that a wide range of users can easily access.

If your users are internal, that expands your deployment options. Obviously, if users are in the same building as you, you don’t have to count on them finding your application. You can simply tell them where it’s going to be.

With internal users, you have the option of preloading the application on devices, such as computers, tablets, or phones. You can direct users to an intranet


ploy

men

t

129

or other internal network where they can access the application. You can even put the application on the web or in an app store, and provide users with a login or password. If you go this route, keep in mind that an application that is only intended for a limited audience (such as your national sales force) may be blocked from general or public app stores. The rules of the app store may require you to establish a separate or private enterprise page or ‘store’ that can be accessed only by your users.

How will your users be trained? If users require training before they can use the application, that will impact how and when you deploy your application. Training is typically associated with internal audiences over which you have control. If users work for your company, you may choose not to distribute the application until training has been completed. Or you may provide access to the application in the first training session.

Training for external users is becoming more and more popular, especially as companies try to ensure user satisfaction. External users may need to access and complete some sort of training module or demo, or even attend a phone-based or in-person training session before they can gain access the application. Or users may get trial access or ‘staged’ access to the application as part of the training or user qualification


ploy

men

t

130

process. In these cases, you will need to consider how and where users will gain access to training as part of your deployment strategy.

Closing thoughts. Deciding how you will give your users access to your application will have an impact on adoption as well as user satisfaction. As you consider your deployment strategy, carefully consider who and where you users are, the type of device on which your application will run, and how much training users need. When you give your deployment strategy attention and forethought, you’ll be in a better position to successfully get your users onboard.

The type of application you create—and the type of device on which it will run—

has a big impact on deployment.

what are my hosting options?de

ploy

men

t

131

Hosting provides a physical location for your application to live and power for it to run. Essentially, hosting is what makes your application available to users.

Your hosting options will vary depending upon the type of application you are creating. For example, desktop, tablet, and mobile applications are typically hosted locally, which means the application lives on (and is hosted by) the computer, tablet, or smartphone the user is using to access the application. But web applications are a much different story.

Hosting for web applications. If you are creating a web application, choosing a hosting option becomes a critical part of your deployment strategy. Unlike desktop and mobile applications, a web application does not live on a local device like a computer or phone. Instead, it lives on a web server that allows it to be viewed on the Internet.

While it’s technically possible to host a web application on your own hardware or equipment, if you are planning for more than a handful of users, hosting yourself probably isn’t a viable option.


ploy

men

t

132

In most cases, you will need to either:

1. Work with a web hosting company. Web hosting companies allow you to rent space on one of their specialized web servers. These servers can be shared or dedicated. With shared hosting, your application will be housed on the same server as other applications and websites. With dedicated web hosting, you will get an entire server dedicated to only your application. Generally speaking, the more hardware or server space your application has, the more users and usage the application will be able to support.

or

2. Work with a cloud hosting provider. Cloud hosting providers include Amazon Web Services or Microsoft Azure. Cloud hosting typically costs more than web server hosting. But if your application is going to have a very large number of users, like 10,000 or more, cloud hosting platforms have the ability to dynamically expand as needed to provide additional power to support heavy application use.

You can pay for different levels of this dynamic support. For example, you can choose a completely elastic hosting environment that expands to support


ploy

men

t

133

any number of application users and any amount of use. Or you can decide to expand only up to a certain number of users.

Closing thoughts. Hosting is an important part of the deployment decision, specifically for web applications. Before you choose a hosting option, carefully consider how many users and how much usage you expect your application to have. Then be sure to choose a hosting solution that can provide enough horsepower to keep your application running and provide a good experience for all your users.

? ?

Before choosing a hosting option, consider how many users and how much usage you expect your application to have. Make sure

that the solution you choose will provide a positive experience for all users!

why does an app need to be managed?m

anag

ing

134

All too often, creators of applications believe that once they have planned for, built, and deployed their application, their job is done. But the reality is, the job is merely morphing into something new—another job that’s perhaps even more critical and more involved than the initial tasks of building and launching the application.

Once the application is live, you transition from application creator to application owner. And just like the owner of any product, you have a responsibility to manage and maintain your application so that it continues to deliver value to your users as well as your own organization throughout its lifecycle.

Applications are living, breathing entities. Just like a website that never changes, applications grow stale and users lose interest if the content always remains the same or the application is not updated from a design or functional perspective. A key component of managing your application is keeping the content, design, and functionality fresh and up to date.

The frequency with which you need to refresh content depends heavily on the type of application and the kinds of content it includes. But with all applications, content should be regularly updated to give users a reason to come back and/or to stay current with the


anag

ing

135

way the application is used.

Analytics and user feedback inform application management. If you choose to include an analytics component in your application, you will have access to invaluable information that lets you know exactly how users are using the application. Depending on who your user base is, you can also gain user feedback by surveying users or staying abreast of user comments posted in app stores, social media channels, and other outlets.

However you obtain user feedback, leverage it not only to evolve and update the features, functions, and design of the application, but also to support and market the application in ways that are most beneficial to your users. By continuously improving your application’s functionality, support, and marketing, you ensure that it remains relevant to users for the long term.

Leverage analytics and user feedback to evolve your product, but also to support and market it more effectively.


anag

ing

136

Closing thoughts. You wouldn’t invest in a new car if you didn’t plan to maintain it. In the same vein, you shouldn’t put the time, effort, and resources into creating an application if you don’t have a plan for evolving and managing it throughout its lifecycle. Even if you’ve built an outstanding application and experienced a wildly successful deployment, applications simply don’t last long if they aren’t properly managed. But if you develop the mindset of a product owner, and if you take the time to create an application roadmap for managing your application’s lifecycle, then your investment in the application is much more likely to payoff. And your application has a better chance of attracting and retaining the users you want.

$You shouldn’t put the time, effort, and resources into creating an application if you don’t have a planfor evolving and managing it throughout its lifecycle.

what is an application roadmap?m

anag

ing

137

An application roadmap is a detailed plan for managing the lifecycle of your application. This, of course, includes the release of new versions of the application with new features and functionality. But a roadmap is much more than a release schedule. The most successful and strategic roadmaps also include plans for user support, marketing and promotion, and assessing the value of the application as it evolves.

Let’s take a closer look at the components a comprehensive application roadmap should include:

Release Schedule No application ever goes live with every feature and function in place. When you were in the Preparing stage of the application creation process, you created a list of functional requirements for the initial version of the application as well as features you hoped to include in future versions. Now that your application is live, you have user feedback and/or analytics that will give you a good idea of the features and functions your users want most.

As a key part of your application roadmap, your release schedule will spell out which features you plan to deliver and when you plan to deliver them, in order to satisfy your users’ wish lists as well as your own business objectives. The application roadmap should


anag

ing

138

also include a detailed release plan that defines how and where updates will be made available to users.

Your release schedule and release plan will take into account the type of application and your user base. For large web and enterprise applications, the rule of thumb calls for quarterly updates and one major annual release. Mobile apps are often updated on a monthly basis. These standards are good guidelines to keep in mind as you work out your release schedule. But ultimately, your plan will be based on the size and complexity of your application and the unique needs of your users and business.

Training and SupportWhen you first launched your application, you should have created a support plan outlining your strategy for supporting users. As part of your application roadmap, it’s important to consider how support activities and user training will need to adapt or change as your application evolves and new functions and features are built and released.

For example, if the application will grow in complexity, additional training and new types of support may be needed. This, in turn, will have an impact on your release schedule because you will want to make sure users have the time to train or otherwise get up to speed with the latest release before you introduce


anag

ing

139

even more features.

Marketing and Awareness When you release new features or versions of your application, you will need to let users know. Again, marketing plans depend a lot on the type of the application and whether users are internal or external. And you will probably leverage many of the techniques you used to create initial awareness of your application.

But now that you have users onboard, you probably have new ways to communicate with them. Perhaps you’ve collected user contact information. You may have analytics data that allows you to tailor marketing plans to individual users. In the case of mobile apps, you may be able to communicate updates via the app store that distributes your application. Considerations like these need to be factored into your plans for marketing and promoting your application on an ongoing basis.

Value AssessmentAs your application grows and evolves to meet your users’ needs, you need to make sure it continues to meet the needs of your business. Your roadmap should include directives for regularly evaluating your application and ensuring it maps back to your original application objectives. If it doesn’t, or if your business


anag

ing

140

objectives have changed over time, you may want to consider how you can revise the application—and your application roadmap—to better achieve business goals.

Closing thoughts. Applications are living, breathing technology products that have to flex and adapt to meet changing user and business needs. As a result, they typically exist in an ongoing cycle of development and release. A thoughtful and comprehensive application roadmap considers how the application itself will most logically evolve, as well as how training, support, marketing, and evaluation efforts should evolve along with it. With a good roadmap, you’ll be in a position to successfully manage your application and ensure its value throughout its lifecycle.

A good product roadmap can help you successfully manage your application and

ensure its value throughout its lifecycle.

creating a retention strategyre

tent

ion

141

You’ve worked hard to create an application and get it into your users’ hands. Once your users are on board and successfully using your application, you may think your job is done. But the reality is, you still have work to do to keep your users engaged.

When you create a user retention strategy, you give thought and consideration to what needs to happen to continue delivering value to users so they will stay engaged with your application. Some important tactics to consider as part of your retention plan include:

Training and support. One of the keys to delivering value is making sure users know how to use your application correctly. If possible, consider providing some sort of training so users can start using the application successfully right away.

Keep in mind that even if your training effort is stellar, users will likely still encounter problems or have questions at some point while using the application. Having a support plan in place ensures you are ready to respond and resolve issues in a timely manner so users can get back to using the application ASAP.


tent

ion

142

Gaining user feedback. When you know what your users like about your application—and what they don’t—you’ll be in a much better position to promote the value of your application and/or to tweak the application to better meet users’ needs.

If users are internal to your organization, or if you have a direct connection to them, you can just ask them for feedback. For external apps distributed via an app store, you can review user ratings and comments.

But if you really want to know how your users are leveraging the application, consider investing in analytics. Analytics can tell you who is using your application and what features or functions are being used, right down to the individual user level. This information is invaluable when it comes to communicating with your users, understanding how the application is being used, and fine-tuning your application.

Ongoing promotion and marketing. Part of keeping application users engaged is constantly reminding them of the value the application delivers. Regularly communicating with users, reiterating the value of the application, and reminding users to take advantage of the application’s features and functions helps encourage continued application


tent

ion

143

use.

Version updates.Adding new features or functions to your application is a great way to continue delivering value and keep users on board. New versions of the application are especially effective if they take user feedback or analytics information into consideration. Be sure to balance any plans you’ve made for future versions of the application with the information and requests you are receiving from your users.

Closing thoughts. Basically, retaining users comes down to continuously delivering the value users want and expect and giving them new reasons to stay engaged with your application. Even with internal applications that are supposed to be used as part of a user’s job, you still need to deliver value. Otherwise, your application won’t meet your business objectives and will ultimately end up in the application graveyard. But if you make the effort to give users what they want and need through training, support, communications, and updates, your users will reward you by staying loyal and faithfully using your application.

importance of analyticsre

tent

ion

144

Deciding to include analytics in your application will give you invaluable information about how your users are using the application. You will see which features they are using—and which ones they aren’t. You can get data that shows you in general what all your users are doing. Or you can zero in a specific user’s use patterns.

The data gleaned from analytics can ultimately be used as part of a retention strategy to help you keep the users you’ve worked so hard to gain.

The benefits of analytics. Analytics data can dramatically strengthen your retention efforts in two different areas.

1. Application enhancements.You can use analytics data to improve or enhance your application based on users’ likes and dislikes. For example, you can:

• Add additional features and functionality that are most valued by users. • Delete features that aren’t being used or that don’t add value in order to streamline the application. • Learn the pace at which you need to expand or release new versions in order to keep your users interested and engaged.


tent

ion

145

2. Marketing and promotions. Knowing what users are doing allows you to create tailored marketing communications. You can:

• Market your application to individual users based on the features they are, or are not, accessing. • Promote the use of specific features so that users realize the full potential of the application.• Encourage dormant users to reengage. For example, if a user has created an account, but has not completed his profile, you can email that user and remind him of the benefits of creating a profile.

What types of applications benefit from analytics? The short answer is all applications benefit from analytics. But analytics are most often used when:

• The application is intended for an external audience. With internal audiences, you have other ways to collect user feedback (though none are quite as effective or comprehensive as analytics.)• The application costs money. Understanding what users value is key to your pricing strategy and can help you add additional features that can justify a higher price. • The application’s functional footprint is a reasonable size. It’s obviously easier and more cost effective to put analytics behind a mobile app with limited functionality than it is to incorporate analytics into every area of a SaaS web application


tent

ion

146

with hundreds, if not thousands, of individual features.

Too often, analytics are left out of an application because of time or budget. And that’s unfortunate because analytics provide a true window into user activity. No matter who your users are or the type of application, analytics give you the visibility you need to successfully improve and promote your application and keep your users engaged. As a result, analytics very often pay for themselves.

How do I incorporate analytics into my application?Ideally, the analytics approach should be defined as part of the application architecture process. Essentially, you have three options: you can write custom analytics code. You can leverage and analytics service. Or you can embed an analytics tool into the application. Click here to learn more about application architecture.

Closing thoughts.Analytics gives your retention strategy teeth. When you base application improvements and marketing strategies on how your users are actually using the application, you are much more likely to provide value to users and keep them engaged with your application for the long haul.

why do i need a support plan?su

ppor

t

147

Up until this point, you have put a lot of time and effort into planning and building an application that will meet your business objectives and your users’ needs. You may have carefully marketed the application to make users aware of its purpose and value. And you may be planning to provide user training to teach users how to take advantage of the application’s features.

But no matter how many t’s you’ve crossed and i’s you’ve dotted, once you release your application and get users onboard, inevitably those users are going to have some questions. And that’s where a good support plan comes into a play.

Being proactive and taking the time to consider how you will support users before you go live means you won’t be caught off guard when users need help. The following considerations can help you create a support plan for effectively answering user questions, meeting users’ need, and keeping users engaged with your application for the long term.

How can users pose their questions? The first step in creating a support plan is determining what types of support you will provide. In other words, when users have questions or need help, how will they get answers?


ppor

t

148

You may choose to let users contact you directly. In this case, your options include phone support, email support, and/or live chat. If the application is for internal users, you may also consider a help desk where people can submit requests for assistance.

If you think many users will have the same questions, you may want to consider an FAQ or a searchable help library where users can find answers without getting in touch with you directly. Yet another support option is to offer webinars or user support forums where many users can come together to ask questions and get information.

When will support be available? For each type of support you provide, you need to determine when it will be available. For example, will live chat be available 24/7? Will you provide phone support only during business hours? How long will you take to respond to user emails? Users need to know when they can reach you and when they can expect a response.

Who will provide support? You need to plan for a support staff. Does your internal team have the time and skills to handle all the types of support you plan to offer? If not, you may need to outsource support to a call center or other organization that can field emails or handle live chat


ppor

t

149

on your behalf. Whether you handle support internally or externally, you will need to train and empower the support staff to properly assist your users. And if you do outsource, you need to think about how you will stay informed of users’ concerns, problems, and comments.

How will you address user reviews and ratings? If your application will be available via one or more app stores, users will be able to rate the application and write reviews. Decide who will be responsible for reviewing and responding to reviews, and how often this should occur.

Will you leverage social media?If you plan to promote your application on channels such as Facebook and Twitter, users may post or tweet support questions. Again, you will need to decide who will maintain your social presence and respond to questions and comments.

Will you phase your support? Depending on the types of support you plan to provide, you may want users to progress through various levels of support. For example, users may first be directed to an FAQ. If they cannot find an answer there, they may next be asked to search the help database. Users who still have questions may then be given access to a phone number or email to contact


ppor

t

150

your support team directly.

How will you communicate your support plan to users? Once you have decided on your support model, plan out how you will make users aware of the support options available to them. You may want to include a support or help module within the application itself, especially for external users. You should also come up with a communications plan to promote help desk and phone support hours, upcoming user forums or webinars, and other forms of support.

Closing thoughts.Very often, application owners overlook user support or don’t fully consider all aspects of support—until it’s too late. It you don’t put a support infrastructure in place and clearly communicate it to your users, then users will attempt to get their questions answered by contacting you whenever and however they can. You won’t be prepared to respond to the barrage of questions coming at you from every direction. And when you fail to address your user’s queries, you could jeopardize the user experience and lose users as a result.

do i need to train my users?su

ppor

t

151

Whether or not to provide training can depend on the complexity of the application you are creating and who your users are. But for any type of application, providing formal user training is really the only way to ensure your audience uses your application as you intend. Training can go a long away toward creating a great user experience. It can help ensure that users realize the full benefit and maximum value of your application. And it can support user retention.

How is training different from support? User training and user support are ultimately two sides of the same coin. They have a shared end goal: providing users with the information and know-how they need to successfully use your application. In some cases, training can be a component of a user support plan. What’s more, some support tools—such as FAQs, searchable help libraries, and webinars—can also be used for training purposes.

Yet training is fundamentally different from support in a couple of key ways. First, training usually occurs before users dive into the application, whereas support typically comes into play when users need help in using the application or a question arises. In many ways, quality training actually lessens the need for user support because well-trained users will be less likely to experience issues with the application.


ppor

t

152

Second, whereas support typically involves troubleshooting a specific issue or problem with the application, formal training is more comprehensive. Training involves showing users the step-by-step or end-to-end process of using the application’s features and functions to accomplish tasks or objectives. As opposed to solving a specific problem, training aims to make users well-versed experts at using the entire application.

Is training only for internal users? In some cases, being able to provide training assumes that you know who and where your users are. It also assumes you have the ability or authority to bring users together, physically or virtually, to participate in training.

If your users are employees of your company, your sales representatives, or even an existing customer base, this should be relatively easy to do. For these types of users, you have a number of training options available, including:

• In-person or online instructor-led group training.• Self-directed training simulations or modules.• Remote support technology that allows a trainer to take control of a user’s device and walk the user through the application’s features.


ppor

t

153

However, even if your user base is a group of external users over whom you have little (if any) influence, training can still be accomplished. Some options include:

• Promotional videos placed in publically available forums. • Training demos or modules included in the application itself. • Well-promoted training webinars or user forums. • A staged application deployment strategy that allows you to connect with, qualify, and even train users before providing access to your application.

Closing thoughts. Training is an often-overlooked step in the application creation process, especially for creators of external applications. Yet, training is a critical component that can give your users the direction and comfort level they need to fully utilize your application. When you make training a part of your plan to support and retain your users, you not only help users avoid errors, mistakes, and frustrations; you also ensure your users and your business get the maximum value from your application.

conclusionWhew. That was a lot of information to take in. It certainly isn’t comprehensive of everything you need to know to create an application, but hopefully it helped.

The application creation process is a journey that requires you get a couple of key things right:

Definition: Have you defined the objective and how you will accomplish it as specifically and detailed as you can? You don’t know what you don’t know, but to the greatest extent possible you should define as much as you can about why are you are creating an application and what it will need to do to drive the value you want.

People: Do you have a team with the experience and expertise to deliver on the vision and value? If you are going to be engaging with partners, do you know how to engage with them to ensure the work product and value you need from them?

Process: Do you know how you will manage and oversee the application creation process? Are you aware of the key components to the process and how they are interdependent?

Product: Are you prepared to own the product? As the leader of the project and application creation process, you must take responsibility for ensuring the application delivers on the vision.

As you continue on your application creation journey, we want to help and be your guide. Reach out and start a conversation or ask a question.

[email protected]

now, let’s continue the conversation.

contact us today

thank you for reading!

AWH Almost Ultimate_App_ebook

Software

Transcript of AWH Almost Ultimate_App_ebook