Design principles

When designing mobile applications, there are certain common guidelines that will help to get your mindset turned to
mobile world. This section provides basic information about usability and the design process.

 Nokia design principles: These design principles are common for all Nokia platforms and should be considered
when creating content for Nokia devices.
 Design great UX: To let your idea for a mobile application become real, we describe a light process which is
applicable without deep pre-knowledge of user experience. It just requires clear thinking and testing.
 Usability overview: Usability is a big part of the overall user experience: An application with poor usability is not
likely to be rated with five stars in reviews! In this section you can learn more about the basics of usability and
user experience, and how to include user experience design with minimal effort to your own development
process.
 Interaction design: Before starting the actual implementation it’s important to plan how the application will
actually work and how the user will navigate in the application to get the most of it. Here you can learn about
wireframes and UI prototypes, and to best take advantage of them in the development work.
 Visual design: Creating visual design for mobile devices differs from designing for desktop. Some things to keep
in mind are performance, scaling to multiple (small!) screen sizes, and possibly limited set of fonts available, for
example. Learn more about Visual design in this section.
 Nokia design principles

Nokia design principles

These design principles are common for all Nokia platforms and represent Nokia’s idea of good design. Keep these
things in mind to make sure your application will be a success.

Less is more.
 Keep it simple, easy, and intuitive to use. M ake it obvious what your application does and how it works.
 The application is lean. There is no extra content. The application works fast and is powerful.
 The structure is flat. No deep hierarchy and endless scrolling.
 The design is elegant and simple and works without exceptions.
Every pixel counts.
 Remember that mobile devices have limited screen real estate.
 Consider ergonomics and the size of peoples’ fingers when laying out your application and designing controls.
The minimum dimensions for touch areas are 8 mm for thumb, 7 mm for finger, and 5 x 4.5 mm for pen.
Natural interaction.
 The interaction is familiar, clear, and trustworthy.
 Basic interaction should be achieved with touch.
 Be consistent, logical, and coherent both within the application and within your target platform.
 M ake sure that you use terms consistently.
Remember the user.
 What does the user want to do with the application? Keep the big picture in mind when designing the application.
 M obile devices are used in different situations. Check that the application can be used in those conditions where it
should be used, e.g. in a bus, outdoors, in a noisy environment...
 You are creating the application for the end user, not for yourself.
 The application is intuitive and fun to use.
 The application makes the user smile but not laugh.
Use fonts and colours wisely.
 The fonts you use are clear and easy to read from small screen.
 Check that the contrast is clear enough.
 Use a limited number of colours.
 Remember the colour metaphors and cultural differences in perceiving colours.
Don’t be offensive.
 You have only one chance to make the first impression. M ake the most of it.
 Check that the application is in line with the Ovi Store content guidelines.
For more information, see the following PDF checklists:

 User Experience Checklist for Touch

 User Experience Checklist for Keypad
Parent topic: Design principles

Design great UX
What do we mean by UX?
User experience is all the things that make your
application what it is:
 How it looks,
 its choice of features,
 how well it performs, and
 how easy it is to use.

Why is UX important?

What is the benefit of good user

experience?
 It will help to improve your
reputation.
 This will increase your confidence
about the work you are doing.
 M ore people will recommend your
app to their friends.
 They will be more likely to spend
money:
 On upgrades.
 On your next app.
 It will help you compete in the
marketplace.
 If taken care of from the start:
 Architecture will be more stable.
 App requires less fixes.
 Code won't go to the waste bin.
 Less need to re-code views with bad
UX.
 Code will be cleaner.
  App development will be cheaper.

Studies have shown that the majority of

application store revenue goes to apps with
four or more stars.
Good user experience will help you to reach this
goal.

Design process

The design process described in this topic:

 Is a cookbook approach.
 Works well for small applications, like mobile apps.
 Will create a solid UX but no genius design.
 Generates also a UX map for :
 Planning app architecture.
 Verifying use cases.

Design process in a nutshell

To let your idea for a mobile application become real, we describe a process which is applicable without deep pre-
knowledge of user experience. It just requires clear thinking and testing. The process is built on the idea that people
have a goal when using an application. This could be playing a game very well or looking for new information.
People want to reach a goal in the easiest way which might not mean with "fewest clicks". The easiest way is found if
people "float" to the goal, i.e. if all their actions feel natural and logical without any extra work.

Ask yourself: how would I reach this one goal if I would not have the phone?

The process can be split into 5 basic steps:

 Finding your “big idea”.
 From ideas to goals.
 From goals to flows.
 From flows to views.
 From views to tested views.

Following these steps you can create a ready UI concept for your application. It will contain an abstract UX map and
detailed sketches of your views.

Sample application "MyKahvi"

To explain the process, we created the sample application concept M yKahvi.

 The main features are:
 Pre-order a coffee and pay the coffee in advance.
 Enable people to pick the coffee when you enter the store,
no waiting time.
 Only one coffee can be ordered at a time - due to logistics
reasons.

In addition, there should be some nice gadgets like:

 Show the opening hours of the coffee shop.
 Guide people to the coffee shop.
 Show images from inside the coffee shop.
 Show what music is playing right now in the coffee shop
and buy it.

Finding your "big idea"

“The best way to have a good idea is to have lots of ideas.” — Linus Pauling, US chemist (1901 - 1994)

How does an idea turn into a product? And how do you get the idea in the first place? M ost good ideas come from a
combination of world knowledge and special knowledge.
World knowledge is the stuff you already know about the world. This can include things you have learned about
science, geography, politics and even history and sports — it is your general education. S pecial knowledge is based
on your personal interests, personal experiences like profession and hobbies. For example, due to a past career or
hobby, you may know how difficult it can be to manage cash flow when running a small business. You may also
know how challenging it can be to stay motivated while training for a marathon.
Combining world and special knowledge can lead to brilliant ideas you would never have thought of otherwise.

This is how it
works:
1. Write on file
cards (for
example, 100
cards):
 S pecial
knowledg
e facts
which
seem
important
to you,
 World
knowledg
e facts
which
were
important
to you
 during the
last days.
2. Try
to combine th
ese cards. Try
again. And
again. You
will not find
the idea yet.
3. Put the cards
aside and
sleep on it.
4. The idea will
come by itself
— make sure
you have
something to
write it down
on.

Let's take the example application M yKahvi. The original question was how to improve the service by reducing the
waiting time during rush hours. The service was analysed (becoming part of the special knowledge) with a simple
method:
Asking 5 times "why?"
 Why is the service so slow? Because there are more people than what we can handle.
 Why can't you handle more people? Because there are just two barristas (the persons who make your coffee).
 Why are there just 2 barristas? Because there is not more space.
 Why is there no more space? Because the space is divided into desk and kitchen.
 Why can't you use the kitchen as well? Because the kitchen should be hidden from the customers, so there is no
direct connection to the kitchen. There is no meaningful way to connect it to the service desk to serve people.
These findings, own business analysis, and some basic technical research resulted in special knowledge. In addition,
there is some general knowledge about people and coffee:

S pecial knowledge:
 Provider billing is now available to up to 15 Euros a day.
 The average coffee order is 4,05 Euros.
 Backoffice service is faster.
 Not possible to have additional service personnel behind the counter.
 Kitchen is used for preparing goods (for the display case, for example) and to bake cookies in the morning and at
noon, but empty otherwise.
 Service is faster if the customer already knows what she is going to order and no questions or other additional
customer interference occurs. Payment takes a substantial time of the order.

World knowledge:
 People are in a rush in the morning.
 People do not like to wait.
 People like to drink coffee in the morning due to the caffeine that wakes them up and makes them ready for the
day.
 M ost people in this country own a mobile phone.
 Coffee can be kept warm.
Shuffling these facts back and forth resulted in the idea of M yKahvi.

Create your elevator pitch

 An important skill when developing an app is the ability to clearly explain what it does to other people. A great way
to do this is to prepare an elevator pitch.

Explain your idea in 4–5 sentences in 30 seconds:

 What are the key things the app will do?
 Why is your app cool or superior to other apps?
 Why would someone want to spend time using
it?
 What are the main business reasons?

Optionally, add the business model. For example:

 Are you using in-app ads?
 If you are selling the app: how much will it cost?
 If your app is free: will there be add-on features
via in-app purchase?
 Is the app created to improve sales of your
standing business?
 Can people donate to your account?

Writing an elevator pitch is an important step in clarifying your idea and can come in handy throughout the project:
 You may need to find friends, partners or investors to help with the app. The more clearly you can explain the
concept, the more likely you will be able to convince them to help.
 When you eventually launch the app, you will need to write marketing copy for the Nokia store. Portions of your
elevator pitch can be used to quickly and clearly explain to users why they just have to get it.

As you begin to develop the app, you may come up with interesting features that don’t quite fit your original vision.
Your elevator pitch will be there to remind you of the key benefits of your original idea. This may help you decide
whether these cool new features will improve your app or whether they may detract from your original vision.

For MyKahvi the elevator pitch could be like this:

 During rush hour people may have to wait too long to get our or competitors' coffee, and that is why people do
not enter our shop if there is a queue of more than 5 people.
 We improve our service with a mobile application, from which people can order and pay the coffee in advance.
 Those people come to the shop and pick the ready coffee from a locked shelf, by showing a QR code from their
mobile phone to a scanner.
 This way we can hire an additional barrista who works in the kitchen which is empty during rush hour, and there
she can take the orders from a screen and prepare the coffees.
 We can advertise this service and due to shorter waiting time expect an amortisation of the investment in less than
2 years.

Crosscheck your idea

You now have an idea that the team really likes. But is it any good for a larger audience? Will “real people” actually
find it useful? One way to ensure you build a product with real people in mind is to do some research.

When to do research? Research is not a one-time activity. Your app can benefit from small amounts of research
performed at different times. Here is an example of research we might perform for M yKahvi.
Beginning of the project
 Observe coffee shop customers to generate ideas for features that might convince them to spend more money or
visit more often.
 Assess the app’s potential market reach. For example, count the number of coffee shop customers who own a
smartphone or tablet.
 Review competing applications and comments from users on blogs or the app store.
 Read the reviews:
 What features do competing apps have in common?
 What do their customers like?
 What do their customers think is missing?
 What could be improved?

Middle of the project

 Watch people use a prototype of the app. This can help discover unexpected things people would like to do with
the app and ways the prototype can be improved.
 Usability study, short and simple.

Close to or after launch

 Interview a few users to discover interesting or unexpected ways that the app is being used. You might discover,
for instance, that people are using the app to track how much money they spend each month on coffee. Could this
behaviour turn into a useful feature?
 Assess the app’s success. How many people are using it? Which features are they using most often?
 Read your reviews and count the stars you earn.

Tip: If you already have a general idea of the kind of app you want to build—for example, something to do with
photography—but don’t really know where to start: you could also perform a small amount of research before your
first brainstorming session. Speaking to or observing potential users can provide valuable ideas to help kick-start
the idea generation process.

Tip: Get the people who will help you build the app to participate in the research. This will help them better
understand the app’s potential users and their goals.

Links and resources

 Find inspiration by listening to the challenges and successes of other developers on Nokia’s Success
Stories YouTube channel.
 If you’re looking for great ideas for your first (or next) Series 40 web app, these webinars (part 1 and part 2) are
for you. Tapan Acharya, lead evangelist and consultant with Nokia in Bangalore, p resents ideas and concepts that
can be developed as Series 40 web apps.
 This section contains a guide to developing applications for different markets including China, Europe and India.

Moving from ideas to goals

Once you have your big idea, the next step is to begin working out your application’s key features. A great way to
begin is by brainstorming. Brainstorming is a simple process that helps generate and refine ideas. It is also an ideal
way to involve other people you know or work with in the design of your new product.
Our goal during this brainstorm is to think of the primary goals people will have when using your new application.
We can then build features to provide them with the tools they need to complete each of these goals.
 Now, let’s get started with brainstorming features for M yKahvi!

S tep 1 – Find participants for a brainstorming session:

 If you work alone:
 Friends.
 Other people who have an interest in your
application, for example:
 supporters, or
 business angels.
 Target users if available.
 If you work in a team:
 Team members.
 Other stakeholders.
 Target users if available.
 No special skills required.
 Create a nice atmosphere and offer some coffee
or other (hot) beverages.

S tep 2 – Introduce the project:

 Explain the idea.
 Utilise the elevator pitch:
 Enough information to set people's mind into the right
direction.
 Not too much information to restrict people from
creating their own thoughts and ideas.

S tep 3 – Quiet time:

  Give each
participant a stack
of sticky notes.
 Everybody
takes 10 to 15
minutes to indivi
dually think of
user goals and
write each on a
sticky note.
 Each goal should
begin with “I
want to…”
 Write down all
goals you can
think of—even if
you’re not sure
they are realistic.
 Never restrict
ideas. Let them
fly.

S tep 4 – S haring the goals:

 Each
person
reads
their
goals
out
loud.
 Goals
are
stuck
on a
large
free
area,
e.g. on
a wall.
 Group
simila
r
goals.
 If
necess
ary,
find
new
headin
gs for
a
group.

S tep 5 – Vote for the goals:

 Vote for
your
favourite
s.
 Everybod
y gets the
same
amount
of votes.
 There
should be
less votes
per
participa
nt than
goal
units.
 An
example:
 7
single
goals
and 6
group
s of
goals
= 13
goal
units.
 Divid
e 13
goal
units
by 2
= 6,5.
 Roun
d up
result
s into
7
votes
for
each
partic
ipant.
 Give one
vote to
each goal
or to a
group of
goals
which
you think
is
important
.
 Use
different
 colours
or signs
for each
participa
nt to
track the
amount
of votes.

S tep 6 – Count the votes and

prioritise:
 Highest amount of votes
— must have features.
 M edium amount of votes
— use ranking to decide:
 importance,
 likelihood that a
feature is going to be
implemented.
 Zero votes — do not
implement, but keep the
idea for later.

One of the benefits of this method for generating features is that it takes into account several people’s opinions. If you
love a particular feature but it received only one vote (yours) or no vote at all, this will provide an important reality
check. The features you choose must be truly useful to the people who will use the app. These people may not all
have the same goals as you do.

When voting for user goals, remember to also take into account your business drivers. Will the app make money
directly? Or will you use the app to make money somewhere else? One of M yKahvi’s business drivers is to increase
coffee sales. Certain features may sound like fun, but it’s important to consider whether they will help us meet this
important business goal.
However, it is important to note that this method cannot compete with professional (and expensive) user research, but
it is a good way to set goals and you can achieve it with no or very little budget. But if you have the budget for a
professional user research for goal definition, utilise it at all costs.

Rethink the app if your main goals get only a small amount of votes.
 Moving from goals to flows
Thanks to the last few steps, we now have a great app idea, and a list of key features our application will need. With
this in hand, it is now time to begin designing the app itself. This next step will transform our list of user goals into a
detailed list of application views.

Let’s get started using one of the user goals from M yKahvi: “I want to rate my coffee”.
The first step is to decide what bits of information the user might need to see once the goal has been reached.

In this example:
 The user should be able to see their rating next to the coffee’s name.
 It would also be nice to see this coffee’s average rating, taking into account other people’s votes.

This completed goal will serve as the end of our flow.

Our job is to now fill in all the necessary steps to reach this goal, beginning with the most likely starting point for the
task (which in our case is the application splash screen). Here is an example of the steps in the “I want to rate my
coffee” flow:
 Flow begins on the splash screen.
 The user can see the Start view.
 The user selects “Coffees and Syrups”.
 The user selects their coffee type from the list.
 The user selects the “Rate my coffee” option.
 The user rates the coffee.
 A confirmation message is displayed.
 The flow ends. The user can see their rating, and the average rating on screen next to the coffee’s name.

Click here to see a larger PDF copy of all flows.

Tip: Write each of these steps on a post-it note. This will enable you to easily move them around.

Repeat this process until you have created one flow for each goal. Here is an example of all the goals and
flows from our coffee shop application.
DOWNLOAD: Click here to see a larger PDF copy of all flows.
Tip: If you get stuck and don’t quite know how to complete a flow, put it aside and move on to another. You will
probably find that the missing bits become more obvious as you complete more flows or begin composing views.

Grouping the flows

Next, we need to figure out how many views the application needs, and what content and components will be
contained in each view. To do this, we need to group flows that contain similar steps. For example, many flows
(labelled in green in the image below) include the step “select coffees and syrups”. These steps all represent the same
application view.

Click here to see a larger PDF copy of all flows.

We can group these steps by simply reordering the flows so that the steps appear side by side. We should also look
for and group steps that are different, but will probably share the same view.
In the example below, the step called “select one syrup” has been grouped with the step “select one coffee” (both of
these are in blue). This makes sense, because the previous step (called “select coffees and syrups”) indicates that one
view will contain a list of all coffees and syrups.
Click here to see a larger PDF copy of all flows.
The final step is to clean up our flows by collapsing the step at the end of each flow and removing all the sticky
notes that show duplicate steps.
Once this is complete, we now have a UX map: an abstract representation of the app that we can use to quickly show
people what the application does.
DOWNLOAD: Full PDF version of our UX map.
DOWNLOAD: Larger PDF copy of all flows.

Moving from flows to views

Now that we have a completed UX map, we can begin to plan our app’s navigation and compose our views.
The first step is to look for ways to reduce the need to click on menus, or drill down to find information. As an
example, let’s try to simplify the steps needed to view all the “About” information of our UX map.
 The current UX map includes lots of useful information about the coffee shop, but getting to this information still
requires lots of clicks.
 To see the opening hours, the user must select “information about this place”.
 To see the list of who is working today, the user must select “crew list”.
 To see how many seats are free, the user must select “information about seating”.
 To find out what song is playing, the user must select “music information”.

Why force the user to click a button, and load an entirely different view to see these four things? Why not put the
opening hours, crew list, seating and music information right on the About view? Doing this will improve the app in
several ways:
 It will simplify the UX map.
 It will save the user valuable time by reducing the number of taps or clicks.
 It will create a glanceable view full of useful information.
 It will reduce the amount of programming and testing.

By removing the selection step, and placing the information right on the screen, we now have a far more useful
“About” view.

Composing the view

Now that we know what content needs to be shown in this view, how do we decide where to put the data?

The first step is to review the votes we assigned to each of our goals to determine each feature’s priority. For
example, out of all the goals in the About section, the “See the opening hours” received the most votes. We should
therefore give it first priority in our view. Next in line was “View the current crew list” and “About us”. These should
also have high priority, but not as much as the opening hours.
Once we have determined the basic priority order for each feature, we also need to ensure the user interface we are
designing makes sense for the platform. Before designing the view, be sure to review the platform’s user
experience guidelines and the different components that are available. Using the correct components, and placing
them in the correct spot will create a more consistent and usable experience.
The example below shows our finished sketch for the About view of a Series 40 Full Touch M yKahvi application.

Links and resources

 To help you design your app's UI, we offer visual design stencils for each platform. These stencils provide you with
graphics for the platform's components, which you use to create screen designs on paper or using graphics editors
such as Adobe Illustrator, Adobe Fireworks, and Inkscape. Download the latest versions here.
 Series 40 Full touch stencils
 Series 40 Touch and type stencils
 Series 40 Web App stencils

S eries 40 full touch UX documentation

 UI Style Guidelines for designing Series 40 full touch applications.
 An in-depth guide to Series 40 full touch components.
 Improving the branding of your Series 40 full touch application.
 Understanding and designing in-app purchase mechanisms for your Series 40 full-touch application.
 A guide to creating new icons for your Series 40 full touch application and a downloadable icon toolkit.
 A downloadable set of Series 40 UI component demos that demonstrate the platform’s different patterns and UI
components.
 Series 40 Full touch UI style guide webinar and slideshow part 1 and webinar and slideshow part 2.

S eries 40 Touch and Type UX documentation

 This guide provides an overview of the Series 40 6th Edition, Feature Pack 1 Touch and Type UI, by describing
its essential components.
 A detailed guide to creating icons for Series 40 Touch and Type devices.

S eries 40 non-touch


 An in-depth guide to the design of applications for S eries 40 non-touch devices. This guide includes an
outline of common components, UI patterns and a platform-specific UX checklist.

S eries 40 web applications

 Detailed information about Series 40 web app design, including common components, icon design and navigation
patterns.
 Xpress Web App Builder (currently in beta) is a new online tool that guides you through the process of creating
rich web apps, with no coding required. Select from a variety of templates, customise your theme, and then add
clipped web content, RSS feeds, and social media information.

Windows Phone
 This section contains an extensive guide to designing for Windows Phone devices.
 A selection of Windows Phone design resources including icon, screen design and sketch templates.
 Videos from Windows Phone Design days including guidance on the use of pivots and panoramas and the use of
core controls and animation.
 Learn more about making smart decisions when theming your Windows Phone application.

More resources
 A webinar and slideshow full of design tips for Series 40 game developers.
 Visit the visual design section to learn how to improve the look and feel of your application.

From views to tested views

“If a user can’t use it, it doesn’t work.” — Susan Dray
 “Supposing is
good, but
finding out is
better.” —
M ark Twain

We have
chosen our
features and
designed all
the
application
views, but
before we
rush out and
build the
application,
we have one
more
important
step: testing.

See it this
way:
 You test
your code
for being
error-free.
 You
should
also test
the UX for
being
error-free.

All
applications
benefit from
testing. The
key is to:
 Test
early —
test the
idea, test
already a
paper
prototype.
 Test
often —-
run many
but short
tests (few
participant
s).
 With this you
will:
 Fail
fast —
find UX
problems
before you
start
coding.
 Fail
cheap —
no need to
throw
away code
because of
bad UX.

Note: It is easier to throw a concept sketch on a piece of paper to the waste bin than to delete your code.

How to test?

The main idea

is that you:
 Test every 2
weeks.
 Test with
only few
participants
(2-3).
 Will have as
many
participants
as one large
usability
study by the
end of the
project.
 Improve
your app
after each
test round,
so people
do not
report all
the same
problems
again.
 Try to use
the target
audience as
test
participants,
but do not
get stuck
with it.
  Use people
who are not
familiar
with the
application.
 Watch what
they are
doing.
Participants
do not
always
speak their
mind
sincerely,
but they
cannot fake
what they
actually do.
 If available
later on, test
with a real
device, not
within the
emulator.
 Test in real
context,
such as:
 loud
noise,
 only one
or no
hand
free,
 poor
lightning
,
 poor wi-
fi signal
or signal
loss,
 stress
and
rush,
e.g.
getting
informat
ion
before
you
enter the
bus.

Try yourself: What went wrong?

 Watch the videos. Figure out what went wrong. How would you change the application? You can find solutions in
this Wiki article.

Links and resources

 Webinar about testing: "Debug your design" with Wiki companion article, recording and slide deck.
 Learn to build simple paper prototypes using this video tutorial from Nokia.
 These videos from M icrosoft provide insights on how to improve your application through quick and dirty UX
testing and how to improve the perceived performance of your application.
 Improve your application by learning more about the practice and benefits of usability.
 Improve the design and performance of your application by learning how to design and optimise graphics for your
Series 40 application.
 A handy checklist of the most important UX issues when designing applications for Series 40 full-touch
devices.
 Test your application for free, on real devices using Nokia's Remote Device Access service.
 How you design and present monetisation interactions requires as much attention to user experience as does the
rest of your app. This presentation walks you through the recommended flows of several monetisation stories in
Series 40 full touch and demonstrates common mistakes that can affect monetisation.

Usability overview
Usability is a big part of the overall user experience: an application with poor usability is not likely to be rated with
five stars in reviews! You should consider different kinds of users, the various environments they use the application
in, and simplified ways of completing the tasks your application is meant to help them with.

Figure 1. Introduction to User Experience at www.developer.nokia.com/Design/User_experience

In this section you can learn more about the basics of usability and user experience, and how to include user
experience design with minimal effort to your own development process.
 About usability
Parent topic: Design principles

About usability
A general definition, as provided by ISO 9241-11 (1998), defines usability as follows:

Usability is the extent to which a product can be used by specified users to achieve specified goals with effectiveness,
efficiency, and satisfaction in a specified context of use. This means that usability is not a property of the product
itself - it is a property of the entire system, including the product, the user, the user's goals, and the context of use.

Figure 1. Definition of usability by ISO 9241-11 (1998)

 Context of use
 Usability measures
 Benefits of usability
Parent topic: Usability overview

Context of use
A successful interface is not just about looks and functionality —it is about the user’s experience of using it. M ost of
us have experienced applications with both good and bad user interfaces. The bad ones cause frustration and don’t
deliver the desired results easily, and in the worst-case scenario we give up and stop using the application.
Applications with a good user interface offer what is termed a ‘seamless’ user experience, where we use the interface
 effectively, without even seeming to think about it. The positive experience that results from this kind of intuitive use
is a major factor in differentiating one application from another, and in being designated a user favourite.

Figure 1.
Samples of good and bad user experience

If you have a clear idea of the context of use, it will help you focus on and identify what the usability requirements
are for the application. It can also provide a framework within which to conduct usability testing.

Designing a mobile application presents a different challenge from designing software for stationary desk use. The
challenge is not just related to physical constraints such as display size and user input methods; it is also
about ‘context of use’. A good user experience can be created from an understanding of who the user is, what his or
her tasks and goals are, and what environment the application is going to be used in. These factors create the context
of use and should always be considered throughout the design process.
 Users
 Tasks and goals
 Environment
Parent topic: About usability

Users
When designing a user interface it can be easy to fall into the trap of basing design decisions on biased or narrow
assumptions of ‘what the user wants’ or even the designer’s personal preferences. The best way to avoid this kind of
mistake and to identify genuine user requirements and preferences is by conducting user research.
Whatever the type of application, a design decision made with a real understanding of the target user’s motivation for
using and interacting with the application will always be a better decision.

We all know that people differ in characteristics due to their culture, gender, age, education, experience, and life
situation. Even within our own immediate circles of friends and family there can be a wide range of differences, so
imagine how big the differences can be between people of all ages on different continents from different cultures who
are speaking different languages. All of these people may have access to your application, but often it is almost
impossible to create an application that meets the requirements and preferences of every single one of them. One of
the first decisions you need to make when designing an application is who your application is for, that is, your target
market. This will give you the framework for designing an optimal user experience.

The Persona tool can help with this aspect of the design process by bringing in different user perspectives. Personas
allow a designer to view a design from a perspective that s/he might not have considered because of his or her own
personal characteristics. Personas can also be a real asset when there are several designers working on an application,
ensuring that the team shares a common design focus.

Figure 1. A sample persona

Usability testing offers designers an additional means to explore and evaluate the design by finding out how actual
users interact with the application. Does the user understand the graphics and the metaphors? Can the user easily find
where to insert information and how to navigate within the application? What information does the user find to be
most relevant, and is that information easily accessible? Results from the usability test will help confirm whether or
not the design is good, and guide design improvements.
Parent topic: Context of use

Tasks and goals

In order for users to reach their goal they will need to complete certain tasks. With knowledge of the starting
conditions and the ultimate goal, the user’s journey to reach that goal can be broken down into tasks. For example, if
a user is on holiday and wants to use his mobile device to share a sunset view with a friend working in an office far
away, the user will have to go through a series of steps to achieve that goal: Take the photo, attach it to a message,
look up his friend’s number from a contacts list, address the message to his friend, send the message. How well and
how easily users achieve their goals depends on how well the application has been designed.

It is also important for users to know that they have achieved their goals. Therefore, the application needs to provide
feedback to the user.
Users often have expectations about the particular steps needed to reach a goal, based on previous experiences and
habits. In other words, the user expects the application and different UI elements to function in specific ways based
on previous experience as well as what s/he intuitively feels to be right for the task. A well-designed application
should support these expectations. By really knowing who the users are and how they think, a designer is better able
to break down the journey to the users’ goal into a sequence of task steps that create a good user experience.

M atching tasks to user expectations is important for a seamless user experience within an application, but it is also
necessary to remember that the application functions within the context of the mobile device it is running on, and that
users expect consistency across all applications on that mobile device.

By conducting usability studies during the design phase of application development, designers can observe and test
the user’s journey and see if that journey meets the user’s expectations. Usability studies also allow designers to
compare alternatives at the application design stage. Testing designs at this stage allows changes that only require a
redesign, rather than recoding of an already written application.

Parent topic: Context of use

Environment
A stationary environment is a place that is familiar to the user, such as a home or office. This environment is more
predictable, and users know where they can find the information, tools, or people they need to help them achieve their
goals. Also, users have generally set up their stationary environments with facilities for obtaining what they need, so
stationary environments are often extremely supportive.
By contrast, the typical mobile environment changes rapidly and is more challenging—for example, access to the
information, tools, and people needed to achieve the user’s goals is often limited or nonexistent. In a mobile
environment, users may employ strategies that are different from what they would use in a stationary environment.
They may, for example, make greater use of preprepared information and materials, or rely on much more succinct
communication and input. Users also face breaks in connectivity, power shortages, incoming calls taking precedence,
or social or security constraints that limit the information they are speaking or keying into a mobile device application
(for example, privacy issues when taking public transportation). Additionally, the response speed of an application is
often critical in the mobile environment, for example, showing a GPS location on a map.

M obile environments also create opportunities. With the inclusion of cameras, GPS receivers, accelerometers, NFC,
and other environment sensors, mobile devices now offer a platform for a unique type of design—design for the
modern mobile environment.

Application design should take account and advantage of the particular challenges and benefits of the mobile
environment. It should make the most of the opportunities that mobile device platforms and the mobile environment
offer to enhance the user experience and to differentiate itself from the stationary environment. Studying the effects
of environmental context on the target user’s interaction with an application can help designers create an application
that is more robust at seamlessly meeting users’ needs in the mobile environment.
Parent topic: Context of use

Usability measures
Taking into account the context of use – user characteristics, tasks and goals, and environment – usability work
attempts to examine and improve levels of effectiveness, efficiency, and user satisfaction.

Effectiveness

The effectiveness of a system means the completeness and accuracy with which users can achieve their goals (ISO
9241-11, 1998). That is, users should be able to perform their tasks correctly with a mobile application. The
application has to give users feedback that helps them decide whether they managed to perform their task in the right
way. In a mobile context, the user should be required to acknowledge important feedback: if distracted, the user
might not notice the feedback at all.

Efficiency

Efficiency may be measured by the time it takes to perform given activities, the number of steps required from the
user, and the number of errors made during use. In mobile contexts of use, the user typically does not have much time
to use the application, so the application must offer fast ways for achieving the goals. For example, the number of
steps the user has to take should be minimised for frequently performed activities. Additionally, consider offering
shortcuts for power users.

User satisfaction

User satisfaction with a mobile application is important in order to encourage the users utilise it - that is, the more
satisfied the users are, the more likely they will use the application. Usually users are not eager to learn to use a new
device or application, unless it offers them significant advantages when compared to existing tools. Importantly,
satisfaction levels may change during the learning phase. For example, at first users may be reluctant to change their
working habits, but later they realise that the new ways of working are actually easier than the old ones.
Another important factors for user satisfaction are personal experience, and simply delight. When the users find an
application particularly useful and personal for themselves, and there is a sense of trust and intimacy, they are more
likely to keep using the application. Likewise, visually pleasing and positively surprising design can give a pleasant
user experience which can encourage use via aesthetic delight.

Parent topic: About usability

Benefits of usability
Benefits of usability work are diverse, and in some cases they are perceived and experienced long after the project is
completed. Typically, the more people use a design, the greater the benefits of investing in usability, since the
benefits come from the added value that ease of use brings to each user. Additionally, usability improvements can
be relatively cheap to implement when compared to normal changes in application development projects.
On the other hand, making correct design choices in early design phases may reduce the need for expensive
changes later in the project, and reduce the need for maintenance and support. For example, dropping application
features or changing the terminology in the user interface can be major usability improvements that are usually fast
and inexpensive to implement (whereas significant resources can be spent on technical modifications to software).
The following figure summarises some documented benefits of usability work conducted in software development
projects.

Figure 1.
Benefits of usability work

With enterprise applications, investing in the improvement of a product's usability provides several benefits for the
customer organisation that is purchasing an application, the actual users, and the development organisation selling the
application.

If an application is designed according to good usability principles, the customer organisation can enjoy increased
productivity resulting from more efficient task sequences of the new tool when compared to the older ones.
 In addition, the training costs and users' resistance to change their working habits are likely to be reduced if the
application is easy to learn. From the users' point of view, good usability facilitates using the application by making
it more efficient and pleasant. Similarly, the development organisation benefits from increased sales and customer
satisfaction as well as reduced costs. Investment in usability can lead to an increase in return customers and improve
the developer's and publisher's brand.
The overall effect of these usability improvements on the user experience can be immense.

M ore information on the benefits of usability can be found on the web site of the Usability Professionals' Association.
Parent topic: About usability

Interaction design
Interaction design is the act of defining the behaviour of a product or a service. Interaction design is essentially
communication: gathering product requirements, analysing user needs and turning them into design that allows users
to effectively perform their tasks on a target platform or device.

 M obile design environment

 Deliverables of interaction design
 Designing for touch
Parent topic: Design principles

Mobile design environment

Interaction design for mobile applications (pieces of software with a graphical UI, operating within a mobile device)
differs from other domains through a few important characteristics, all explained in the following:

 Adherence to a consistent UI style

 Hardware limitations
 M obile use context
The limitations are strict, and there are also strict rules on what can be done – the rules define a sandbox where the
designer has freedom to manoeuvre.

Web designers entering the mobile domain may find that they can now focus on the essential application features and
user interactions, without having to include “everything for everyone”.

Adherence to a consistent UI style

In the mobile world, the impact of UI style is far more concrete than in Web or desktop domains. Different mobile
platforms, such as S60 and Series 40, define their own basic set of rules, for example, in terms of display area and
content, keypad interaction and UI components that are available.

Consider an example from S60:

 Figure 1.
Example of S60 UI style

Users of a particular device platform are accustomed to using the UI in a particular way, and all new applications
must take these preexisting habits into consideration. M obile applications are seldom used individually – they are
used alongside and in context with other applications in the device.

M obile applications are rarely targeted to a single device. By following a platform style, the designer can ensure that
the application works on a large number of different devices. The UI style and UI components are the toolbox for
developing new applications. The UI style shows how applications should behave, and UI components provide the
building blocks on which applications can be created.

Even when an application design deviates from the standard UI style with customised design, the designer should
know the target platform style in detail – knowing the rules allows breaking or bending them with successful results.
The designers’ challenge is to innovate within the set rules.

Hardware limitations

Within the mobile domain, the design must consider the following limitations:

S mall display sizes. With a small screen, the amount of simultaneously visible content and controls is limited. In
many cases, the user is forced to scroll or pan the view to see more. Small display sizes limit the lengths of UI text
strings, such as softkey labels or menu commands.
Limited input methods. M ost devices have small ITU-T keypads for text input, navigation keys and a few control
keys used for softkey actions or accessing special functions. Some devices may feature QWERTY keypads or virtual
keypads.
 Limited processing and network capabilities. M emory and processing capabilities and the variety in network
connection speeds may increase the duration of performing an action. This may result in significant lags in UI task
flows.
Wide variety of devices. Even within a platform, there are several different devices with different capabilities, such
as display sizes and processing capabilities. Applications are usually designed for the entire platform – not just to a
single target device – and should consider issues such as scalability to different display resolutions.

Mobile use context

M obile devices and applications are used in a significantly different cont ext than desktop applications. A mobile user
may be practically anywhere, under any conditions when using the application.

Figure 2. M obile use locations and conditions

The mobile user may be

 Using the device while moving

 Performing another task at the same time

 With or without a network signal, or with a slow data transfer connection

 In an extremely dark or bright environment

 Running out of battery

 In an extremely noisy or distracting environment

While the design cannot be prepared for every possible situation, the key to mobile design is to keep it simple.

Simplicity is achieved by focusing on the most important features and keeping the design clear and accessible. Users
should be able to perform key tasks with low effort and important information should be easily available.
The mobile use context also offers exciting possibilities to the designer. For example, users are likely to always have
their mobile device with them – application designers can rely on the fact that their services may actively get the
user’s attention when necessary.

Device technologies such as accelometer sensors or location-awareness of the device increase the possibilities for
innovative application design.

Parent topic: Interaction design

Deliverables of interaction design

This section describes the various deliverables from the interaction design process. Deliverables are used to
communicate the design to different stakeholders at various milestones within the project.

By reviewing the deliverables internally – or utilising them for user testing – the progress and direction of the design
can be monitored throughout the process. Up -to-date documentation makes changing the design later, such as for a
new release, more efficient.

The deliverables are explained in the following. Depending on the complexity of the design and the required level of
detail, deliverables can also be combined.

Navigation maps

A navigation map describes the hierarchical structure of the mobile application. In addition, the navigation map
specifies the interconnections between different application views and how the user can navigate forward and
backward within the application.

Figure 1. Navigation map

 The navigation map corresponds to a site map in Web design, but adds more detail on the navigation possibilities
while a site map simply describes a hierarchy.

Wireframe models

Wireframes are visual representations of the contents of an application view, adapted to the scale and size of the
target device display. Wireframes define all functional and content elements in the view.

Wireframe models are the culmination of all previous input for the design: business and user requirements,
objectives, feature selection and content.

Wireframes are not intended to reflect the final design or to include polished graphical elements.

The purpose of wireframes is to:

 Communicate the design at a phase when it is still easy to make even radical changes through iteration.
 Allow focusing on the functionality.
 Promote debate between all stakeholders, such as business development and coding.
 Provide input for subsequent process phases, such as user testing, graphical design, UI specification and
implementation.
There are different types of wireframes:

Figure 2. Different wireframe types

 Hand-drawn sketches are a quick way of conveying a view layout. The low-fidelity format encourages
experimentation and honest critique in a participatory design session with target users, for example.
 Annotated wireframes describe the functional elements. View objects can be explained in annotations alongside
the diagram.
 High-fidelity wireframes are mainly produced for testing purposes. The wireframe model is supplemented with
draft graphics, colors, correct fonts and typography.

Figure 3. Wireframe sequence

Wireframes work best when used as a sequence. A sequence can illustrate navigation paths and user interaction with
the application.

UI prototypes

UI prototypes are not mandatory or standard deliverables of the interaction design process. However, they can be
created based on the design wireframes if necessary.

Ranging from paper prototypes to functional and interactive simulations, prototypes can be used to verify and
validate the design with the target users. Prototype testing reveals design flaws early and allows changing the design.

When developing mobile applications, a working prototype or a demo is also an excellent communication tool within
the organization. When different stakeholders can take a hands-on approach to the design, they can better express
their opinions and ultimately avoid miscommunication.

UI specifications

After the design has been finalised and frozen, a detailed UI specification can be created. A UI specification defines
all details of the application behavior so that that implementation does not have to resort in guessing.

A full UI specification may involve a large amount of effort, depending on the complexity of the application. The
need for detail is also dictated by the project organisation: if the designer is available for continuous consultation by
the implementation team, a lower level of detail may be acceptable.

On top of the navigation map and wireframe models, a full UI specification includes:

 Description of every view.

 Definition of which UI components are used in individual views.
 Action descriptions (menu contents and softkey actions and labels).
 Keypad actions, if other than default.
 Unique IDs for all graphics and icons.
 Unique string IDs for all text strings to be localised.
 Specification on how to handle exceptions from normal behavior or error cases.
 Preliminary content for notifications, error messages and tooltip texts.

Parent topic: Interaction design

Designing for touch

Touch screens enable direct manipulation of content and objects and offer a natural interaction with the device. This
means a new user experience and interaction style. When designing applications for touch screen, try to minimise
user input. Using a touch screen increases the risk to make errors in inputting data, compared to using a keypad.

All applications designed for touch devices should be touch-enabled, meaning they can be used with the touch screen
alone, without a keypad.

However, the core of non-touch Nokia platforms still remains its scalability, wide range of options, wealth of
multimedia features, and language support.

The application features must follow the platform support for different hardware. Potential target devices may or may
not have a hardware keyboard.

There are two touch screen technologies in use, and you need to take this in account in your design:

 Resistive touch screens can be used with either a stylus or a finger. Resistive touch screens offer a high
resolution and durability.
 Capacitive touch screens can be used with a bare finger, or with a conductive device held in a bare hand. An
ordinary stylus cannot be used. Capacitive touch screens have high clarity.
Design should enable completing a task with the same interaction method as it was started with. With devices that use
resistive touch technology, consider the use cases of the application when deciding whether to use finger or stylus
control, or possibly hardware keys. Eliminate the need to switch from using a finger or stylus to using the hardware
keys.

Note: If your application is intended to be used with the stylus rather than a finger, present this clearly to the users. It
can be frustrating to start using an application with finger touch, then switching to stylus, for example, if the
components on screen suddenly get smaller.

Decide whether the application is to be used with a single hand, or two hands. M ake sure users are able to use at least
the most important functions with only one hand. With touch screen devices, this means that the users should be able
to perform most basic actions with their thumb.

Applications that require the use of both hands include the following:

 Applications that require the use of stylus.

 Applications that are intended for landscape mode.

 Applications that require data input.

For more information about Maemo touch components, see Hildon 2.2 UI Style Guide at Nokia Developer.
For more information about S ymbian^3 touch components, see Nokia Symbian^3 Developer's Library at Nokia
Developer.
For more information about S 60 5th Edition touch components, see S60 5th Edition C++ Developer's Library at
Nokia Developer.
For more information about S eries 40 Touch and Type touch components, see Series 40 Touch and Type UI Style
Guide at Nokia Developer.
For more information about the size and positioning of UI controls, see Scale and positioning of controls.

 Touch strategies
 Usability considerations
Parent topic: Interaction design

Touch strategies
In touch devices, there are two main interaction strategies: strokes and gestures. Strokes are performed by moving a
finger or stylus on the touch screen. Gestures involve moving the device itself. Additionally, it is possible to use
buttons, switches, or other controls based on the touch screen actions.
Strokes and gestures should be taught and indicated to the user. It should be clear to the user where on the screen
strokes can be performed. M any users like to use traditional interaction methods such as buttons and sliders in
addition to strokes or gestures; this way, they are available as backup, if the correct stroke or gesture is forgotten.
 Figure 1. Visual instructions in Bounce touch

For instance, even if zoom functionality is provided using strokes, providing a slider pop -up in the toolbar can be
useful.

Tip: With strokes and gestures, clear feedback is necessary so that the user acknowledges that the gesture is
registered.

 Utilising strokes
 Utilising gestures
 Touch-enabled vs. touch-optimised
 Interaction with hybrid devices
Parent topic: Designing for touch

Utilising strokes
In a single tap UI, focus is not available by default. Instead, items are highlighted with a touch down event. The
highlight disappears with touch release, and the appropriate action is performed. In case a submenu or stylus pop -up
menu has been opened, the highlight stays to indicate which item the touch event applies to, and disappears when the
submenu or the stylus pop -up menu is closed.

The basic stroke interaction is a single tap (also called short tap). In a single tap, the stylus or finger is placed down
and lifted up again on the same item within a short period of time. When creating custom UI components, base the
design of the interactions on single tap.
Long tap, drag, flick, and pinch are direct selection events, where the user taps on the screen and holds the touch for a
period of time, or strokes the screen without lifting the stylus up.

 Long tap can be used for providing, for example, contextual options, stylus pop-up menu or help, which can also
be available through the Options menu. Long tap works best as a shortcut to more information or options of an
object. However, as it may not be clear to the users which items have long tap events attached to them, the design
should not rely only on these events.
 Drag can be used, for example, to move items from one location to another.
 Flick in different directions or on different areas of the touch screen can trigger actions. For example, in an image
viewer application, you can swipe the screen with the stylus or finger horizontally to go to the next or previous
image.
 Pinch is a two-finger stroke used to zoom in or out in capacitive touch devices. To pinch open, place two fingers
close together on the screen and move them apart without lifting them from the screen. Similarly, to pinch close,
move the fingers toward each other. Pinch stroke can be used, for example, in an image viewer to zoom in and
out.

Touch screen strokes can be used in cases that require direct, intensive, and focused interaction. The most intuitive
touch screen strokes that can be performed using a single finger are linear, sweeping movements.

In addition to linear strokes, drawing shapes like circles or crosses on the display is considered intuitive for some use
cases.

The example strokes illustrated above could be used for confirming or cancelling an action, or rotating an image or
object in an application.

Tip: Strokes generally work best in full-screen applications, where users do not need to worry where the stroke can
be performed.
The application needs to provide tactile feedback for each touch screen event. For more information, see Feedback.

Parent topic: Touch strategies

Utilising gestures
In addition to the basic touch strokes, some devices contain sensors which allow for more complicated gestures.
Gestures involve interacting with the whole device, such as tapping the side of the device, or shaking the device.
Gestures are not obvious for the user, and must be either discovered easily or communicated clearly.
Sensors can work together with the UI to allow for more complicated gesture combinations. When the interaction is
based on detecting movement of a handheld device, the user interface becomes as tangible as the device itself. This
provides a new user interface paradigm where the whole physical device can be used for performing gestures

Freeform gestures are suitable in use cases that require immediate, fast response.

Unlike strokes, there are no universally intuitive gestures. Some general use cases where users naturally propose to
use gestures are waking up the device, lights on, mute and volume adjustment, deleting items, zooming, moving to
next/previous item/screen, and yes/no confirmation.

Tip: Freeform gestures that many users find natural include tapping, turning, shaking, swinging, tilting, and flipping
the device, and moving the device left/right/up/down.
 Rotating the device horizontally on the X-axis can be used efficiently for left/right controls. For example, in a game
context, this type of movement can be used for steering an object left or right.

Tilting the device on the Z-axis either horizontally or vertically can be used, for example, for browsing galleries or
other media items.

Parent topic: Touch strategies

Touch-enabled vs. touch-optimised

Rather than being touch-enabled, applications can be touch-optimised, that is, designed primarily for touch screen
interaction. When developing applications for a touch interface, consider which interactions benefit the most from a
touch UI. While physical strokes and gestures provide a natural interaction with objects, the fact that one can apply
them does not mean they are appropriate for every situation.

Here are two tips for designing applications for touch use. First, base your design decisions on real, considered touch
use cases. Second, as touch functions require a fair amount of discovery from the user, make only the most obvious
functions touch-enabled.

Why to use touch

 More flexible: Compared to fixed hardware keys, the interface can change dynamically. This allows for flexible
configurations depending on the functionality needs, languages, and so on. Thus, even a very small screen can
include several button sets. Also, with indirect strokes and gestures, there are numerous possibilities. No use of
physical buttons is required.
 More intuitive: M anipulating objects directly by touching them is natural and intuitive. Keyboards, mice,
trackballs, and other input devices are not able to convey as much subtlety as touch can. Direct manipulation can
deliver a lot more meaning to controlling a tool.
 More fun: You can design a game in which the user presses a button, and an on-screen avatar swings a tennis
racket. It can be simply more entertaining to mimic movements physically and to see the action mirrored on-
screen. Strokes and gestures encourage play and exp loration of a system by providing a hands-on experience.
 More engaging: Through play, users start to engage with the interface, first by trying it out to see how it works.
Limitations of touch
 Heavy data input: A hardware keyboard is faster for most people to use when entering a large amount of text or
numbers, and applications which involve heavy data input are not necessarily ideal for touch devices. Virtual
keyboards are adequate, for example, for messaging applications. Consider using adaptive methods – such as
options and selections filtered according to what is available on the screen or in a list – and pre-filled items, when
possible.
 Reliance on the visual: While touch devices provide tactile feedback capability, some applications can rely
heavily on visual feedback to indicate actions. Provide scalability, larger buttons and text sizes, for example, for
visually impaired users.
 Reliance on the physical: Touch interface can be more demanding on the physical context than mechanical keys.
Tapping a touch screen button while wearing winter gloves, or with long fingernails can be difficult, for instance.
The inverse is also true: the more subtle and small the movement, the less likely it is that everyone will be able to
do it. To overcome this, the most basic use cases, such as answering an incoming phone call, must utilise large
enough elements and straightforward interaction.

Parent topic: Touch strategies

Interaction with hybrid devices

A device can have a combination of touch UI and hardware keyboard interaction. If the user uses touch UI only, there
is no visible focus available. However, when the user presses a hardware key, the focus becomes visible and
disappears again when the user continues using the device with touch. When hardware keys are taken back into use
again in the same view, the focus appears in the position where it was when touch was taken into use. The first
hardware key press activates the focus, the second press performs an action.

When the focus becomes visible, item-specific options are also updated in the Options menu, and the hardware
shortcuts are available for use (for example, pressing the Send key to activate a call).

See Nokia Symbian Developer's Library for more information on the Symbian implementation.

Parent topic: Touch strategies

Usability considerations
All touch interfaces have to appear competent and safe. Optimising system performance is critical here. Low screen
refresh rate and latent images do not give the impression of a trustworthy touch UI. The use of touch screen and
sensors may also increase battery consumption of mobile devices.

Note: Touch screens consume most power during touch operations, and reducing unnecessary user interaction can
help increase power efficiency. Specifically with resistive touch screens, it is recommended to avoid excessively long
touch and drag actions. The continuous touch event flow keeps the CPU busy. The screen lock turns off the touch
completely.

Interaction design

A good product predicts the needs of the user and then fulfills those needs. Adaptive targets are one w ay to do this.
Controls that match the users actions well are another way devices can be clever.

Use appropriate and simple interaction logic:

 Navigation and controls should be clear and meaningful to prevent mistakes: strokes along the touch panel should
produce a logical outcome.

 In indirect controls, the UI response should relate to the action the user is performing.
 M eaningful controls are easy to learn and remember.

Touch UI can employ direct or indirect controls, or a combination of both:

 Direct controls allow users to simply tap the item they want to manipulate right on the screen itself, move it, make
it bigger, scroll it, and so on.

 Indirect controls use other means to manipulate an object, for example, shaking, tilting, flipping, waving and so
on.

 While the Nokia UI style allows the use of scroll bars, it is common to reverse the page scrolling orientation in
applications such as the browser. In absence of scroll bars, users will flick or drag the page upwards rather than
pull a scroll bar down to move the page up, that is, to scroll down. In this case, scroll bars are used as navigation
indicators.

Direct taps and strokes are far easier for the user to understand and pick up than abstract, indirect ones. A single view
should always employ only a few indirect strokes, so that the controls do not confuse the user.

Visual design

M ake a clear distinction between touchable areas and non-touchable areas, such as text.

 Borders, glow effects, or other indicators can be used to highlight the interaction.
 Note that theme design alone is not sufficient for indicating touch functionality: where one theme may indicate
touch, another may not.

For more information, see the Visual design section.

 Scale and positioning of controls

 Feedback
Parent topic: Designing for touch

Scale and positioning of controls

Touch interface elements should not be smaller than the smallest average finger pad, that is, no smaller t han 1 cm
(0.4") in diameter or a 1 cm × 1 cm square.

The target minimum sizes for UI elements should be finger usable:

 7 x 7 mm with 1 mm gaps for index finger usage.

 8 x 8 mm with 2 mm gaps for thumb usage.

 A minimum of 5 mm line spacing in list type comp onents.

Note that the given target sizes are general and may vary in practice. The visible area of the component and the
component’s active area should be identical.

The width of a finger limits the density of items on screen. If the items are too close, t he user will not be able to
choose a single one.

As the user is more likely to touch higher on the button by mistake than on either side, consider the height of your
buttons and icons.

Never place essential information or features, such as a label, instructions, or sub-controls below an interface element
that can be touched, as it may be hidden by the user's own body.

 In interfaces with traditional input devices, it makes sense to place targets like menu items on the edges of
screens: the user cannot overshoot the target, as the cursor stops at the edge of the screen.

 When using a touch screen, a user seldom drags his finger across the screen as he would with a cursor. Instead,
they most likely lift their finger and place it on a new target. Users may have difficulties in reaching the objects
located on the edges of the screen, especially if the physical device has protruding edges around the touch screen
panel. Additionally, with some devices, the screen edges may be less sensitive to register the touch input.

Parent topic: Usability considerations

Feedback
Visual feedback is the most important sensory feedback when entering characters on screen. Visual feedback can be,
for example, button effects, colour changes, status indicators, touch/release state changes, or clearing the screen when
transitioning to next screen.
 With audio feedback, lower tones are preferred over loud beeps, even though some people turn audio feedback off.

Vibration is used as tactile feedback for touch screen interaction or input. Tactile feedback gives the user an
immediate response that the touch event has been registered, and can even be given in noisy environments.

Note: Tactile feedback is included in those common UI components where it is beneficial. When creating new
applications and designing custom components, include tactile feedback where found useful. For example, in any
button, the tactile feedback is beneficial.

Providing tactile feedback reduces the number of mistakes made by the user. It also improves user performance in
terms of speed and accuracy, because tactile feedback is perceived more quickly than visual or audio feedback, which
can be difficult for users to perceive when they're distracted or on the move.

Furthermore, tactile feedback is silent, nonvisual, and individually communicated; it can be used for communicating
information privately.

Tactile feedback provides intuitive and real-time confirmation of an action. When creating custom components,
consider using tactile feedback in the following components:

 Buttons and sliders.

 S trokes and gestures.
 Notifications.
Providing real-time feedback is essential for confirming successful action. Lack of feedback can indicate that the user
lost control of an object and an action was not completed. Users prefer short and gentle vibrations as gesture
confirmation. Audio feedback can also be used, but it should be configurable by the user.

 Use soft feedback for successful actions.

 Use sharper, more disruptive feedback for unsuccessful actions.
Tactile feedback is used to increase usability. When utilising tactile feedback, consider the following:

 Providing tactile feedback increases power consumption. Thus, excessive use of tactile feedback will drain the
battery.

 If tactile feedback is used for every possible UI event, the device will be vibrating all the time, and the vibration
will no longer be meaningful for the user. Additionally, continuous tactile feedback may become irritating.

 When using different vibration patterns, they should be easy to differentiate; at maximum, use seven different
patterns. Rhythmic patterns are easier to remember.

 Vibration sequences should be short in order to keep the feedback pleasant. Avoid sequences longer than 50 ms.

 If audio feedback is used, vibration sequences and audio should be synchronised.

 Tactile feedback should also be supported by a change in the visual style of the element, especially in case of
buttons.

Parent topic: Usability considerations

Visual design
This section provides information and best practices related to visual design in for mobile devices.
 One of the major challenges in mobile design is that there is not only one device or one platform. The static designs
you create may be implemented and ported to multiple platforms and hundreds of devices. The more you understand
these platforms, the features they enable, and how they interact with a given device, the better equipped you are to
create designs that look great, perform flawlessly, and can be ported easily.

Good visual design starts with understanding the device, but consider also this:

 Choose the appropriate theme to address your target audience and make an impression.
 Design your application so that the main features are immediately visible.

 Screen size
 Colours and fonts in mobile
 Transitions
 Graphics and animation in mobile
 Basic principles of visual design
Parent topic: Design principles

Screen size
Unlike PC displays, which have standardised to two or three common sizes, mobile phone displays still come in
many shapes and sizes. The screens have grown larger, while smaller screens still exist at the lower end of the
market. Displays typically support both portrait and landscape modes.

A large proportion of new devices ship with 240 x 320-pixel (QVGA) displays, and with the launch of S60 5th
Edition, we are seeing the introduction of even larger displays — 360 x 640-pixel (nHD) touchscreens —in devices
such as the Nokia N97 mobile computer. M any of the older and entry -level devices currently in use have smaller
displays, including the popular 176 x 208-, 128 x 160-, and 128 x 128-pixel formats.

Figure 1. Screen size progress

There has been steady progress from simple, small-screen devices to today’s large-screen multimedia computers.
Even today, however, low-cost devices such as the Nokia 2323 classic are being released with small, 128 x 160-pixel
screens.
To deal with this diversity in screen size, the common approach in both design and development is to group devices
into families that have common characteristics. Screen size is certainly one of those characteristics. Others may
include browser type, XHTML and CSS support, and colour depth. Once devices are grouped, rules are established to
adapt graphics, layout, styling, or even content for each device family. In the case of screen size, the impact on design
depends in part on the platform you are designing for.

While the more limited devices ship in great numbers, they rarely are ideal target devices for Web or Flash
applications. For Web and Flash, QVGA is a reasonable and safe standard to aim for.

Physical screen size

The display size in pixels is only half the story. As a designer, you should also be aware of the impact that
the physical screen dimensions will have on your designs. Consider the three devices pictured below. Each has a 240
x 320-pixel display, but they vary in physical dimensions and, consequently, in screen resolution.

Figure 2. Physical screen size and

resolution comparison

Each of the three devices shown has a 240 x 320-pixel display, but they vary in physical dimension and, therefore, in
pixel density, which ranges from 154 to 199 pixels per inch.

The implications are most obvious on images, particularly on those that contain graphic text or fine details. All of
these devices share a 240-pixel screen width, yet a logo that is legible at 154 pixels per inch may be somewhat less so
at 199 pixels per inch. Although it probably doesn’t make sense to group these t hree devices into separate families
and create separate graphics for each, this does illustrate the importance of testing designs on real devices early on, to
ensure that assets designed on a large computer monitor are suitable once transferred to a mobile device and that
critical visual elements remain legible at all common or supported screen sizes.

Figure 3. Legibility at
different resolutions

The same content viewed at higher screen resolutions can quickly become illegible.

Parent topic: Visual design

 Colours and fonts in mobile
Colour plays a very important role in visual design. It can assist in the organisation and grouping of information,
helping to focus attention, convey differentiation, and establish relationships and visual hierarchies between elements.
Colour can also help readers scan information and quickly identify structural or functional elements such as headers,
menu items, and hyperlinks. When used incorrectly, however, it can easily distract attention from the task at hand,
create visual ‘noise’, and cause a user to make connections between elements that may not be related at all.

Like computer monitors, mobile devices use an additive colour process. Unlike print media, which begin with a
white surface, the computer screen begins as a black surface to which coloured light — red, green, and blue (RGB)
— is added.
Although early mobile devices supported very few colours, colour support is now quite robust, with a large
proportion of devices providing 12-bit (4,096 colours), 16-bit (65,536 colours), or 24-bit (16 million colours) colour
support. You will find however that — similar to the variety in screen size — many devices in use support varying
colour depths, with newer, low-cost models (such as the Nokia 2330 classic) typically supporting 12- or 16-bit colour
depths.

Figure 1. Bit depth and image quality

Pictured above is a simulation of an image displayed at various bit depths. As this illustration indicates, the vast
majority of Nokia devices are in the 12- to 24-bit range.

In light of the wide variety of devices you may have to support and the often-critical nature of the tasks people
execute on their mobile devices, here are some things to keep in mind when working with colour:

 Don’t rely exclusively on colour to convey critical information such as error messages or network interruptions.
This practice will ensure that users of less sophisticated devices or users in variable light conditions have other
means for clearly understanding the level of importance associated with y our message. Remember as well that
about 10 per cent of men have some sort of colour-blindness.

 If a colour is being used to convey a specific meaning (for example, red to warn of danger or an error), check to
be sure that the chosen colours are universally associated with the intended meaning and be aware of the potential
conflicts that result from cultural misinterpretation.

 Remember the importance of maintaining clarity between figure and ground. Aim for a contrast of 50 per cent —
especially for critical interface elements and body copy. If you are uncertain about your colours, you can convert
your designs to greyscale to see which elements stand out and which blend into the background.
 Complex gradients — those that include transitions involving more than two colours or that follow a complex
path — may not appear as expected, even on newer devices. This will manifest itself as banding between each
area of colour. Avoid using gradients for backgrounds or large areas of the screen.

 Some devices display colours differently from various viewing angles, so test your design by holding the device
in different positions. Remember that unlike desktop computers, mobile devices are not always viewed from the
same angle or orientation. Certain development tools, such as Adobe Device Central CS5, enable simulation of
various display conditions, such as backlight timeout and daylight reflections on-screen.
 Displays also vary in brightness, and the newer devices are not necessarily the brightest. Get to know the
brightness range by testing on multiple devices. Pay particular attention to colour contrast. Black on white will
always create the highest contrast and, as a rule of thumb, you should aim for a contrast of around 50 percent.
Remember as well that devices are often used in sunlight, which further decreases the visible level of contrast.

 If you work with brand managers or marketing departments, try to manage their expectations with regard to
colour accuracy early on. Even devices with identical colour depths can display colour differently, and, because
of differences in colour saturation, it can be difficult to match Pantone colours to a mobile display. Expect slight
shifts in colour — in particular with bluish tones, which tend to have a wider range on devices.

Font support

Font support on mobile devices is limited, and your level of stylistic control over fonts will depend on the platform
you are designing for. All devices support at least one font. This font often serves as the device’s default typeface and
is typically referred to as the native font or device font. For example, S60 devices from Nokia use one font — S60
Sans, designed by M onotype — to render text within the browser and operating system.

Figure 2. The S60 Sans font by M onotype

All device manufacturers provide their own custom device font, so it’s worth taking the time to familiarise y ourself
with each of those fonts.

 If you are designing a Web site that will be viewed in the Web Browser for S60, your ability to affect type will be
limited to basic styling of the size, colour, style (such as bold or italic), and weight of S60 Sans.

 In Java M E development, the formatting of device fonts is limited. The font size can be specified as small,
medium, or large, which should be considered a very rough measure, because the actual size displayed will vary
across devices. You can also specify a limited range of font styles (typically, bold or italic, but, again, not
supported on all devices) and set text colour using RGB components or hexadecimal values.

 Java M E technology also enables you to specify custom typefaces, but the process is quite different from what
you may be used to on the Web or with Flash. Java M E technology doesn’t simply specify a typeface. Instead, a
graphical (or bitmap) version of the required characters is included with the application that then crops and
displays each individual character to form the required words and phrases. While this approach enables you to
specify any font you wish, it also increases the size of the application, may cause performance issues on less
capable devices, and is therefore not recommended for large areas of body copy. Note as well that it is notpossible
to change the colour of bitmap fonts dynamically, so a separate version of a font will need to be included for each
and every colour you wish to use.
 Flash Lite supports device fonts, as does Java M E technology, and also enables you to specify your own typeface
in two ways. You can either choose standard, TrueType fonts or use pixel fonts that are specially designed for
mobile use and to appear crisp at a specific point size. As with Java M E technology, each font bundled with the
application increases the size of the overall file.

Designing for the small screen on a big monitor can be challenging, and the most common mistake is making fonts
too big. Given the variable nature of device fonts and the added impact of physical display size (described in the
previous section), many designers find the creation of accurate wireframes, mock-ups, and documentation
challenging. There are, however, simple ways to improve the accuracy of your designs:

 Gather screen shots of various devices and measure the point sizes of common text -based elements such as body
copy, headers, and softkeys. To avoid last-minute surprises, use these measurements as a guide and crosscheck
your designs well before the porting begins.

 Use the S60 Sans font in your wireframes or designs. You can obtain a TrueType version of the font downloading
and installing the S60 SDK, then looking in the following location on your drive:

C:\Symbian\[version# ex. 9.2]\[release # ex.

S60_3rd_FP1_5]\Epoc32\release\winscw\udeb\z\resource\fonts
 Avoid the use of italic type: It can be difficult to read. Unlike traditional print fonts that typically use a custom
italic variant of each font, device fonts often simulate italics by shifting the upper half of the font slightly to the
right. This approach can decrease legibility at certain sizes.

 Remember that an increasing number of devices support both portrait and landscape modes. These modes can be
implemented in all applications or merely during use of certain applications, such as the browser, camera, or
media viewer. Newer device models, such as a number of the Nokia Nseries multimedia computers, include an
accelerometer, which triggers a change in mode as soon as such a device is physically rotated. This feature further
increases the likelihood that your users will spend time in both modes and emphasises the need to consider both
throughout the design process.

Parent topic: Visual design

Transitions
UI effects are more than eye candy. Well-designed transitions help users and make the UI more engaging. Consider
the following:

 Conform to physical laws to create a pleasing effect. In the physical world, objects do not appear from thin air
or disappear without a trace. Instead, they have an origin and a destination. They also have a trajectory and speed.
These principles of movement, inertia and gradual changes should also apply to UIs. Without transitions, the
interaction feels less natural.
 Maintain intuitive feeling to your transitions. With transitions you can inform the users of what is going on,
present the results of their actions and indicate how objects relate to their environment. For example, you can
flick to browse your home screens on the Nokia N8; when flicking to the left, the current home screen view
moves to the left and a new view comes in from the right. And vice versa.
 Be logical with different types of transitions. When designing transitions, make them logical in a way that
similar functions have similar transitions. For example, in a list each list item should trigger similar transition.
 Use transitions wisely and test how users feel about them. Transitions can easily create a WOW-factor to your
application. However, if every UI element is twitching and turning wildly, it could as easily exhaust the user.
The combination of smart interactions, aesthetic visuals and flowing transitions creates exceptional user experiences.

Download and try out the QM L RSS Reader example application. See also documentation on the implementation.
Parent topic: Visual design

Graphics and animation in mobile

M obile devices support many of the digital-image formats you may already be familiar with, including PNG, JPG,
and GIF. Scalable Vector Graphics (SVG) is also available for mobile technology, through the use of Flash Lite or
SVG Tiny (SVGT). There is, however, a wide range in the level of implementation across devices, platforms, and
manufacturers, so to avoid surprises, discuss image formats and capabilities early in the project.

Graphics within the browser

Common graphic formats such as PNG, JPG, and GIF are well-supported within the browser, with over two-thirds of
Nokia devices supporting all three formats. Support for the more advanced GIF89a format (which includes
transparency, GIF animation, and interlacing) is typically limited to newer devices. To determine whether a device
supports a particular image format, consult the Nokia Developer Devices section or DeviceAtlas, which enables you
to generate custom charts and graphs to visualise image support across devices.

Graphics within native applications

Support for image formats within native applications is also quite strong. The most common difference you will
encounter concerns the handling of transparency when using graphics for icons or interface elements. Not all devices
and operating systems support full 8-bit alpha transparency. Instead, transparency is specified by use of a 1-bit
(black-and-white) or 8-bit (greyscale) mask, which enables you to specify the masked area in white and the visible
content in black or varying shades of grey. In fact, masking in this way is often used as a less processor intensive
technique to simulate animations. For example, in the creation of an animated progress bar, a 1-bit mask is animated
to gradually reveal a full-width, full-colour progress bar below. This produces a rich, animated effect while
manipulating a simple 1-bit image instead of a series of larger, full-colour graphics.

Figure 1. Index and alpha transparency

Unlike index transparency, which is either on or off (that is, fully transparent or fully opaque), alpha transparency
provides varying levels of transparency, resulting in a less abrupt composition.

Scalable Vector Graphics Tiny (SVGT)

SVGT (a subset of SVG) is a language for describing 2D graphics using XM L. SVG enables the creation of
interactive graphical content and the ability to zoom and resize displays with different resolutions and aspect ratios.
In practice, the SVGT format is particularly useful for icon animations, transitions, and other active visual elements.
SVGT is supported on many mobile devices. Actual levels of implementation vary from device to device, depending
on the manufacturer and the installed version of SVGT.
 For Nokia devices, support for SVGT is quite robust:

 S60 3rd Edition devices support SVGT 1.1 graphics. On these devices, SVG content can be viewed separately, or
SVGT graphics can be embedded in applications as UI graphics or icons.
 The S60 architecture also enables widespread third-party visual customisation of the UI through the creation of
SVG-based Themes.
 The Web Browser for S60 contains an SVGT plug-in that makes it possible to view SVGT graphics directly
within the browser.
Devices supporting Java technology may also support JSR 226, an optional component that enables devices to take
advantage of SVGT within Java applications. SVG can be extremely useful for graphic-rich interfaces, because
graphics can simply be scaled to adapt to different screen sizes. This reduces the need to include different-size bitmap
graphics for each device family.
See also Java M E on the Oracle Technology Web site.
Here are a few things to keep in mind when working with SVGT:

 Be sure to save to the SVGT format. At first glance, SVG and SVGT may look similar. However, SVGT has been
specifically optimised to suit resource-constrained devices and supports only a subset of SVG features.
 Beware of images that contain complex gradients, effects (such as drop shadows), or a large number of nodes.
These images — especially animated images — can have a severe impact on device performance.

Animation with Flash Lite

Flash Lite is by far the simp lest yet most flexible platform for a designer, enabling you to use your existing Flash
skills to easily create mobile animations. If you are designing for other platforms, speak to your development team:
There may be several options available for the project, including the use of SVGT, 3D, and traditional sprite
animation. It’s also worth noting that a large number of Nokia devices support GIF animations within the browser.

Similar to Flash, its desktop cousin, Flash Lite supports programmatic and timeline-based animation of vectors and
bitmap graphics. Due to the wide range of supported devices, performance can be a concern, so be sure to consider
the following in the design of Flash Lite animations:

 Avoid complex animations and, in particular, multiple simultaneous timeline-based motion tween animations.
 Start animations with tweens and manually adjust the animations to remove unnecessary frames.
 Avoid unnecessary alpha effects or gradients and don’t combine transitions with changes in transparency or other
graphical effects; these are likely to slow down your animations.
Extensive resources for designers can be found within Nokia Developer’s Flash Lite website and on
the Adobe website.

Parent topic: Visual design

Basic principles of visual design

The same basic design principles apply whether you are designing for small or large screens. On small devices,
however, these principles take on added importance related to the unique characteristics of small-screen devices:
They are always on, they often use indirect manipulation, and they are operated under variable light conditions and
with a high potential for task interruption. These conditions are quite different from the typically relaxed, seated,
mouse-in-hand, big-screen experience on a desktop computer. It is therefore important to take full advantage of
design principles to ensure that your application’s functionality is quickly and clearly conveyed at every step of the
user interaction.
 The Gestalt principles of perceptual organisation
 Achieving unity in design
Parent topic: Visual design

The Gestalt principles of

perceptual organisation
The term 'Gestalt' is a German word meaning ‘shape’ or ‘form’. Within the context of design, the term 'Gestalt
principles' was coined in the early 1920s to describe a design’s wholeness: A design’s unity is more than the sum of
its parts. In other words, each part of a design affects and is affected by what surrounds it. As a designer, you can
apply these principles of perception to organise information and make sure that users will quickly make sense of the
elements on-screen, understand what functionality or data they represent, and make informed decisions about their
actions.

Similarity

We naturally group things that are similar — for example, by size, colour, shape, or style. This principle can be used
to visually set apart certain elements as belonging to a group even if they are far apart. Conversely, through the
creation of contrast, we can place emphasis on or make elements stand out from others. In the example provided
below, the Nokia viNe application uses similarity in colour and shape to group and imply relationships among similar
types of media (in this case, photos and music).

Figure 1. Similarity

Proximity

Elements that are close together are naturally perceived as being related. This principle can be used to organise
content and ensure that critical items such as top -level navigation are perceived as such. Because of the small screen
size, however, the use of proximity may be limited: After all, you can fit only so many distinct groups onto one
screen before they are too close together to be perceived as separate entities. In the example below, Flickr has
grouped navigational links to create a navigational menu but has varied the level of proximity to separate the links
into three distinct groups. By comparison, the Nokia menu is perceived as one single grid because the icons are close
together with no variation in distance.
Figure 2. Proximity

Repetition

This principle states that a repetition in positioning, size, colour, or shape creates a natural unity. This is often seen
with the repetition of a visual element through the use of a tiled background, which creates depth and interest without
appearing busy or distracting the eye from the more important elements of the interface.

Figure-to-ground relationship

This principle states that the most visually striking element is perceived as having focus and relevance while the
surrounding space is perceived as the background. This principle — often achieved through differences in colour,
brightness, or visual accents such as drop shadows — can be used to great effect to ensure pop -up windows, dialogue
boxes, and ‘selected’ elements are given emphasis and appear separate from the content ‘below’. In the example
provided below, both pop -up windows share a colour similar to their background element. To establish a clear figure-
to-ground relationship, the designer has dimmed the background, thus increasing the level of contrast between figure
and ground.

Figure 3. Figure-to-ground relationship

Closure

This principle states that we naturally try to close gaps and make whole shapes from incomplete visual data. In the
example below, the forward control button has been considerably dimmed, creating, at first glance, a large gap in the
circle. Despite this, the music player's control is still perceived as a circular element. The principle of proximity
reinforces this perception. Were the five buttons randomly positioned throughout the interface, we would likely not
have perceived them as a set of related controls.

Figure 4. Closure

Continuation

This principle states that we have an inherent ability to complete visual patterns and arrange elements into a
continuous form. The example provided below shows a series of elements arranged so that they form a continuous
pattern that leads the eye across the screen, either vertically or horizontally.

Figure 5. Continuation

This principle is also the basis of our ability to perceive animation within a succession of images. Short animations
can be used to great effect in mobile devices to attract attention during menu navigation, assisting users in making a
clear connection between the actions of their thumbs on the navigation pad and the corresponding results on-screen.

Parent topic: Basic principles of visual design

Achieving unity in design

Unity is another important element of design. Although there is no way to measure unity, it is typically achieved
when all the on-screen elements feel as if they belong together and were formed or positioned with purpose. Just as a
product or service with a random, mismatched series of features may feel unbalanced, visual elements that are
randomly conceived and positioned feel equally so. To achieve unity, Gestalt principles are used hand-in-hand with
the additional components of design presented in the following.
Space

Space is at a premium on mobile devices, but it is important to retain a certain amount of empty space in all designs.
The proximity example illustrates that crowding the screen can be dangerous because it may become difficult for
your audience to perceive intended groupings or emphasis. The example below also illustrates how design principles
and components work together to create unity in design. Placing the small avatar in the centre of the composition and
with such high contrast establishes its dominance and creates interest. The fact that the map is dimmed establishes a
strong contrast and figure-to-ground relationship, further increasing the impact of the composition.

Figure 1. Space

Visual flow

Guiding the user through your application is important. In the Western world, the eye typically travels from left to
right and — even more so with a mobile device — from top to bottom. M aking use of Gestalt principles such as
repetition and continuation already establishes a certain order to the information on-screen. However, it is important
to ensure your design does not force the user’s gaze to dart around to progress through the content. The next two
design components — dominance and hierarchy — can also be useful in creating visual flow.

Dominance

Dominance is a form of contrast: One element visually dominates another. Example A below provides a clear, high-
contrast element to indicate which item in the navigation has focus. Example B, however, uses a focus element whose
colour is so similar to the background colour that it is barely perceptible. Such a lack of dominance can be
particularly dangerous on a small, portable device because it causes users to stop what they are doing and carefully
scrutinise all elements on-screen to determine which one might have focus. This wastes time, causes confusion, and
can make navigating information a slow, painful task.
 Figure 2. Dominance

Hierarchy

On small screens, establishing a strong visual hierarchy can be extremely useful in indicating relationships between
elements and in guiding the user through the content in a consistent and predictable manner. Here again, design
principles such as contrast and dominance work hand in hand. In the example below, the bright, high-contrast headers
establish the visual hierarchy and help to group the form elements into easily distinguishable sections.

Figure 3. Hierarchy

Images and graphical elements

Images and graphics play an important role in visual design, but most visual elements add weight to a web page or an
application. For this reason, it’s important to carefully consider the message each image or graphical element seeks to
convey and maximise its impact through careful design. Here are some things to keep in mind when creating visuals
for use on mobile devices:

 Keep images simple. If possible, avoid complex diagrams, illustrations, or photographs. If you must include them,
be sure to test them at different sizes, at different colour depths, and on high- and low-end devices to make sure
that critical details are not lost in translation.

 When creating visuals, consider cropping images to ensure that the primary visual element (the person, place, or
thing being depicted), is as big as possible. Background scenery may be attractive, but unless it is the most
important aspect of the photograph, it’s probably not required.
 If you have the option to provide different-size images for different device families, there may also be value in
using completely different images. Imagine, for example, a news article about the stock market. Although a
photograph showing a group of traders on a busy stock-market floor might be suitable for VGA and QVGA
devices, on tiny 128-pixel screens an image showing one trader in front of a screen will have far more impact and
be much easier to understand.

 Vector graphics (such as SVG or vectors in Flash Lite) are becoming increasingly popular on mobile devices
because they can be scaled and yet remain crisp at any size. Remember that simply scaling a vector image to work
on different devices may not be the best option. Although scaling simple interface elements such as tabs and
containers may work beautifully, detailed elements such as icons may lose critical detail when scaled down or
look awkward and incomplete when scaled up.

 Take advantage of native browser and platform capabilities to reduce the use of heavy bitmap images for non-
critical elements. When designing for the web, use CSS-based backgrounds, colours, and borders wherever it is
possible to enhance the information design. CSS support will vary, but this is a great, non-invasive way to
progressively enhance designs for sophisticated browsers. Speak to your development team to learn about similar
techniques using Java M E or Symbian OS technology.

Animation and transitions

Small amounts of animation can be extremely useful on mobile devices. When used judiciously, animation has many
advantages:

 It can help guide the eye through the interface and enhance tasks such as scrolling and navigation.

 It can be used to draw attention to important feedback and provide contextual information about the task at hand.
For example, an animated loading bar provides easy -to-understand generic feedback that a task is still in progress
while also providing specific information regarding its level of completion.

 The use of transitions (animations that lead the viewer from one state to another) can help retain or reacquire
context during otherwise abrupt actions such as a change from portrait to landscape mode.

 The use of easing (a term used to describe the gradual acceleration or deceleration of motion) makes animations
appear more realistic and provides cues that indicate that the action is beginning or ending.

Animation can backfire, however, if it is used too extensively, is triggered too often, lasts too long, or is positioned in
such a way that it detracts from the actual content on-screen. Here are some things to keep in mind when designing
animations and transitions:

 Any animation takes time away from the user’s actions, so use animation sparingly. Test the timing and flow of
the animation on multiple devices to ensure that enhancements on high-end devices do not detract from the
experience on less capable ones.

 Keep animations short and simple. Long, complex animations can cause performance problems that are bound to
negate most of the benefits noted above.

 Speak to your development team to make sure that the animations you are designing can be implemented on all
target devices.

Parent topic: Basic principles of visual design