Instructions<Remove this section if you use this document template for submission>

Design Submission

Nokia Design has two key quality checkpoints from UI point of view

Proof of ConceptKey Use Case Flows, Interaction Maps, VisualDesign reviewed and approved

Quality CheckDesign Updates/Builds verified andapproved

OverviewInstructions

Proof of

Concept

Concepting

Quality

Check

Development

Store QA

Process

Publish

Send to partner

manager

Nokia Design response in 2 business days

Proof Of ConceptNo 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 CheckOnce 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.

UI design toolsUX 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 addedUI 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 toolsInstructions

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.

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

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.

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

<Application name>Design proof of concept

Overall application structure<Application name>

Tips for structureDescribe 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

Launch & Sign in process<application name>

Tips for accessDescribe 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

View name<application name>

Element explanation here

Element explanation here

Element explanation here

Element explanation here

Tips for Main viewsYou 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

Use case name<application name>

Tips for Use CasesInclude 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

KiitosThank You