1. Design Submission

2. Nokia Design has two key quality
checkpoints from UI point of view
Proof of Concept
Key Use Case Flows, Interaction Maps, Visual
Design reviewed and approved
Quality Check
Design Updates/Builds verified and
approved
Overview
Instructions
Proof of
Concept
Concepti
ng
Quality
Check
Develop
ment
Store
QA
Process
Publish
Send to partner
manager
Nokia Design
response in 2
business days

3. Proof Of Concept
No builds needed, but we need to see your interaction maps and visuals to
make sure you’re using the UI effectively. Preferred types of delivery are
PDF or PPT. If you already have a fully functional build with full UI we can
review from that. The submission presentation needs to include at least:
Interaction map (Mandatory)
Main views Visualized (Mandatory)
Key Use case flows (Optional – highly
recommended)
Quality Check
Once you have feedback from the design review, we check the the actual
application build in order to check that application follows the principles from
the proof of concept
The application passes this first milestone when there
are 0 “must fix” issues, and no more than 4 “should fix”
issues.
Nokia Review Requirements
Instructions
The application passes this milestone with 0 “must fix”
issues, and no more than 4 “should fix” issues.

4. UI design
tools
UX Design Guidelines (.PDF)
UI Component toolkit (.AI)
Design template (.PPT / .AI)
Icon creation Tools (.zip)
UI Checklist (.PDF)
Nokia provides a UI design kit for partners who will
be designing their application themselves. The
design kit will be updated on a monthly basis.
UX guidelines are the instructions how to build
the application and the UX checklist will include
the key points of platform UX listed in order to
speed up the review process.
UI toolkit includes the basic building blocks for
application design and Design template is the
document where partner can create and present
their UI concept. Concept can also be added
UI Design kit will be provided to partner as a single
package by the partner manager as soon as there
is an agreement on the features of the application.
Nokia UI design tools
Instructions

5. Design
Proof Of
Concept
UI Design deliverables
Instructions
Design document which describes the
application behavior as good as possible.
Nokia provides this template as an Illustator file
with an example application design in order to
ease the app design process.
In Inhouse concepting model partner needs to
provide document for Nokia design approval
before the development starts. Nokia will then
provide a review report with improvent
suggestions and a fix list.

6. Overall
view of the
application
Design proof of concept - Interaction Map (Mandatory)
Instructions
The interaction map provides the necessary
information both for Nokia design review and for
application developers about the key behaviors of
the application

7. Visual
language
explained
Design proof of concept - Key screen visualized
(Mandatory)
Instructions
For the key screens of the application the POC
document needs to include the key screens. This
gives an understanding about application’s
visual design principles and brand identity.

8. Hero flows
opened
Design proof of concept - Key Use Case Flows (Optional)
Instructions
In order to understand the application behavior
and the key use case flows, the core tasks need to
be documented with use case flows in the POC
template.
Alternatively, a flow description can be
replaced with video or interactive
prototype if applicable

9. Design proof of concept

10. Overall application structure
<Application name>
Tips for structure
Describe what application is and what it does
List the reference platforms (i.e. iPhone / Android / PC applications of the same product or
service)
Provide an overall site map that contains the MAIN application structure in 1-2 slides. This will
help the person reviewing the application to see the “big picture”.
List possible questions / open issues / platform dependencies

11. Launch & Sign in process
<application name>
Tips for access
Describe all the ways user can access the application or the content of it (e.g. Home: Apps
launcher / Activity screen, via Mail attachment, via native platform application etc.)
Describe possible Sign in / Sign up process. Think about possible delays and ways to handle
them.
Think about all the possible scenarios: a new user, a new user that has an account, a power
user, a user that has forgot the password etc.
Use 1-3 slides for different scenarios regarding application startup

12. View name
<application name>
Element explanation here
Element explanation here
Element explanation here
Element explanation here
Tips for Main views
You need to include ALL the main views in this document
If the main view has a lot of interactions it’s recommended to make an interaction maps as
shown in previous slides
In obvious cases the interaction map is not needed. However, all the functionality of the
application needs to be clear for the person that is reviewing the document.
With interaction maps you can describe the content of menus, such as: action menu, filter
menu and object menu
Include 1 slide per main view to this document, check that the main views described in the
overall application structure are defined

13. Use case name
<application name>
Tips for Use Cases
Include all the main use cases in this document
Use text explanations when needed
Use blank screens when platform view (such as Share UI) picture is not available. Explain the
functionality with texts.
Describe actions and gestures with notations. Use flow charts in complex cases (errors
included etc.)
If you face constant changes with frequently used elements (e.g. logo, header bar style, main
view) --> there is no need to update changes every time everywhere. Instead, use one slide in
the beginning to describe changes for whole presentation.
Include 1 slide per key use case in this document

14. Thank You