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 47
planning 54
requirements 63
scope 71
usability 78
wireframes 85
architecture 93
content 100
design 107
development 113
testing 121
deployment 127
managing 134
retention 141
support 147
audience 2
awareness 13
objectives 21
resources 28
strategy 38
46
92
120

who will use your application?
audience
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 users
Internal users are users within your own organization.
External users
These users are external to your organization and
could be customers or future customers.
Hybrid users
These 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.

audience
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

audience
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 diﬀerence between internal, external, and hybrid
users is how much inﬂuence you have over them.

audience
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.

audience
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 expectations
audience
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 users
what they want, because
it will change over time.

audience
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.

audience
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.

audience
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.

audience
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 application
awareness
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.

awareness
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.

awareness
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.

awareness
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 application
awareness
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.

awareness
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.

awareness
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

awareness
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.

awareness
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 buzz
about your application
well before it launches.

defining a need
objectives
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 need
objectives
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 need
objectives
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 what
your competitor’s application
does—and, more importantly,
what customers wish it did.

defining a need
objectives
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 deﬁne the needs that
your application will address.

defining a need
objectives
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 need
objectives
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 need
objectives
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 understand
both the ﬁnancial and non-ﬁnancial
values that your app provides.

forming your team
resources
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 Maker
You 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 team
resources
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 team
resources
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 team
resources
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.
Developer
The 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 team
resources
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 team
resources
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/Team
Whether 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 assets
resources
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.

resources
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

resources
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.

resources
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?
strategy
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.

strategy
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

strategy
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.

strategy
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?
strategy
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.

strategy
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.

strategy
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.

strategy
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
ﬁts into your company’s strategic plan.

experience isn’t always expertise
partners
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

partners
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

partners
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
Expertise
When selecting a partner, look for
someone with the speciﬁc skillset
you need, plus a broader subject-
matter knowledge to best drive
user value.

choosing the best partners
partners
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,

partners
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.

partners
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

partners
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 milestones
planning
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 milestones
planning
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: Design
Using 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 milestones
planning
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 milestones
planning
57
Milestone 7: Production
Following 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 milestones
planning
58
with an application that meets your users’ needs and
delivers significant value for your business.
There are nine key milestones
to develoing an app. How many
milestones have you completed?

managing the project
planning
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,

planning
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

planning
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.

planning
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 requirements
requirements
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

requirements
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

requirements
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.

requirements
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 requirements
requirements
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

requirements
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.

requirements
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.

requirements
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 requirements
scope
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.

scope
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.

scope
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’s
scope before you begin talking with
programmers and designers
to start building.

what drives scope change?
scope
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

scope
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

scope
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.

scope
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?
usability
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.

what is a use case?
usability
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.

what is a use case?
usability
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.

what is a use case?
usability
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?
usability
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.

usability
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.

usability
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?
wireframes
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.

wireframes
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.

wireframes
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 prototypes
wireframes
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.

wireframes
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.

wireframes
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.

wireframes
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.!

architecture 101
architecture
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

AWH Almost Ultimate_App_ebook

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (15)

Similar to AWH Almost Ultimate_App_ebook

Similar to AWH Almost Ultimate_App_ebook (20)

Recently uploaded

Recently uploaded (20)

AWH Almost Ultimate_App_ebook