Upload
krudee
View
1.243
Download
0
Embed Size (px)
DESCRIPTION
Citation preview
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