Telia Play

Product Designer

All about polish
- from Figma to production

As a part of a team with only developers for the following platforms:

TV: TVOS, Android TV, Smart TV
Web
Mobile app: iOS and Android

The UI and UX had fallen behind both in production but also in Figma when it came to file structure, components and more. I came in to support the team with accessibility. But while doing so I identified that this part of the service didn’t follow brand and was lacking UI and UX structure. I started to identify what needed to get done and in what order to pitch why this polish work was needed.

The approach on where to start

  • 1. Analyze the Figma file and components

    What should we know about the services you provide? Better descriptions result in more sales.

  • 2. Audit all platforms

    The navigation pattern etc

  • Understand techinal complexities

    What should we know about the services you provide? Better descriptions result in more sales.

  • Create a prio list with PO + assesment

    What should we know about the services you provide? Better descriptions result in more sales.

  • Info icon

    One goal with the app was to decrease the amount of onboarding time per new workers. An info icon was added with “how to’s”

  • Consistent placement of menu

    With so many steps in the process. A consistent menu was needed - for when things go wrong and the user needs to undo or redo.

  • Active screens

    With a hand held scanner, the user should scan in goods to register in the app. Whenever a user reached that step - they could see an animation to signalate “possible to scan”

  • Highlight value objects

    “VV” stands for value and we wanted the users to be extra cautious and see it right away. I decided to enhance it with color but also change the type-weight to secure for people with color blindness.

  • Step 1 - Conduct Audits

    This is an example of an A/B test where clarity was weighted against how fast the workflow could be. A focused on a clear and recognizable menu option where the use reported per item.

  • Step 2 - Understand technical complexities

    In this B version. We focused more on efficiency in case there was a need to report several items. The user leaves the items unconfirmed and proceed with pressing the main button to trigger bottomsheet.

  • Step 1 - Conduct Audits

    This is an example of an A/B test where clarity was weighted against how fast the workflow could be. A focused on a clear and recognizable menu option where the use reported per item.

  • Step 2 - Understand technical complexities

    In this B version. We focused more on efficiency in case there was a need to report several items. The user leaves the items unconfirmed and proceed with pressing the main button to trigger bottomsheet.

Additional markets

Along the way, it was decided that the Norwegian market which previously had its own design system and features should be included in the design. Norway had slightly different needs due to already established user patterns and country-specific laws. This affected the process in the way that the components needed to be optimized for this. We did not want to clutter the library with more components. Rather enhance and rebuild the ones we did have already.

The Finnish market should also be included with similar needs as Norway. For both markets, the users can record live TV content and after choose to download it.