The document discusses Nokia's process for creating UX guidelines. They took an embedded, agile approach with cross-functional teams that were responsible for developing and testing components continuously. This allowed the guidelines to evolve based on feedback rather than being an afterthought. The guidelines focused on concrete examples like wireframes, designs, code, and prototypes to provide a shared understanding across roles like design, development, and testing. Write access and commenting was open to all teams.

1. UX Guidelines – how we did it at
Nokia
Joel Finnström
Creative Director
Online Sweden
Telia

2. 2

3. Nokia guideline documents
3

4. Guidelines?
The easy part: The hard part:
• A set of UI patterns and • A shared idea
components
• Create buy-in
• A visual guideline
4

5. How did we create buy-in at Nokia
• Embedded process
– Thin management layer is key
– Have a team that can do everything needed to deliver an end result
– Make sure everybody had an understanding of programming
– Guidelines can’t be an after thought
• Agile methodology – embrace change
– A guideline is something that exists, it’s not a theory
– Continuous user testing – no big bangs
– Fail fast and improve continuously
– The cost of changing is always lower than the cost of a bad release
5

6. Business
Design
Design
Development Business
Development
6

7. Nokia Telia
Managers/Leaders
Product Owners
Projectmanagers
Content Managers
Designers
Scrum-teams
Developers
7

8. Team structure
Team
Approx. 5x
1x UX 1x Visual
1x Tester JS
Designer Designer
developers
8

9. Organisation
Development
Central Service
Teams Teams
6
JS 40+ external
Components Maps Store Music
Framework partners
teams
9

10. Organisation
Development
Central Returned fully functional components
every 3rd week. App Teams
Teams
Several JS
40+ external
Component Framework Maps Store Music
partners
teams team
Feed requirements
10

11. Lifecycle
• Each component and pattern went thru several sprints and changed
behavior based on feedback from the product owners.
• Cumbersome but still more effective than waterfall
11

12. What did we document?
• Nobody likes to read
• We focused on examples & concrete rules
– Wireframes (Balsamiq, fully clickable)
– Visual designs (pixel measurements, HEX colors, sizes)
– Code (l33t)
– Prototypes (pixel perfect stuff)
– Pattern Flows (Illustrator is your friend)
• Every profession shared the same page
– Designers, Developers and everybody else wrote their stuff together.
• Mostly everyone had write access & commenting was always
turned on.
12

13. Learnings
• The guidelines wasn’t an afterthought or a separate process; it
was in our daily work thanks to the end to end responsibility
within each team
• It’s more important when NOT to use a component than the
other way around
• The nice guidelines that can be downloaded on
http://harmattan-dev.nokia.com/docs/ux/ wasn’t something we
actually worked with. It’s just marketing made for the release of
the phone.
13