Design submission template
- 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