Simply clever

Simply clever

For the past year and a half I've been on a design team for the Škoda Auto infotainment apps. These enhance in-car experience by for example allowing drivers to pay for parking or manage work meetings and messages easily on the road. As most of this work is under an NDA, I’ll focus on sharing how it helped me grow as a UX designer.

MAIN RESPONSIBILITIES

individual:
UX design, IA, competitor analysis

with a team:
user testing, user interviews, quantitative surveys, data analytics, protopersona development, UI design, contributing to the design system, client cultivation, quality assurance

DURATION

Nov 2021 - July 2023 (1y 8m)

Have a look at Pay to Park- my team designed the in-car part.

LEARNING #1

User testing is fundamental and can be done even with little budget or time

In our team we believe our opinions are hypotheses which need to be verified. That's why we test all of our designs and then iterate them.

We learned to prepare hypotheses, scenario, prototype, recruit and execute the testing in less than 1 week. The earliest you can test in the project the better, because you learn from users not your hypotheses.

However, sometimes there is only little time or budget and many teams ditch the testing altogether. In those moments we test at least with our friends, families or even non-designer colleagues, if they match the target group.

After some time, seeing how useful it is, having the label user-approved is something product teams started asking for themselves.

Testing in car is the most authentic, but requires more set-up. For the apps used only when the car is stationary, it is sufficient to test behind a desk.


Testing on chairs with a tablet is the best fit for rapid testing. This one was prototyped and executed in less than 6 hours.

LEARNING #2

Assure the quality by checking the developed version

Creating perfect designs and documentation doesn't guarantee that the developed app will match them exactly. Technical restrictions we didn't know about or developer errors can cause differences. To ensure quality, we test the developed version and report functional and visual improvements. For example putting a loading screen instead of displaying a screen without text which loads later.

Me checking the code, app design and interactions, and writing a report in Figma.

LEARNING #3

Collaborate with all important stakeholders

Regular syncs with the product team and developers are essential during the design process. They allow for collective decision-making and validating the feasibility of the design. Sometimes, what seems simple to us is challenging to develop, while other times what's overlooked as difficult is suggested as an easy solution by the developers. This approach reduces the need for last-minute design changes after the design handover.

Collaborating in a workshop with devs, PO, BO, marketing, and other designers

OTHER LEARNINGS

  • Preview the designs on your output device- We use infotainment screens or tablets because the interactions, resolution and size are different than on a laptop screen
  • Always visualise your ideas- instead of just talking about how we could design a flow or a screen, we quickly put it together. (Having a design system makes it even quicker.) Ideas visualised seem different than in our heads and this way we make decisions faster.
  • Design with the worst case in mind- ask the developers to send you an average and the longest exemplary data from the API. Prioritise for the most common case, so the designs look as good as possible, but make enough space for the worst case.
  • Try out translations to different languages- sometimes the English text might fit very nicely but translation to languages like German or Bulgarian doesn't.
  • Don't use ”/” in the frame names- fun thing but did you know that once you export a Figma frame with a backslash in its name, it exports it in a subfolder?

Source of the cover photo: Škoda Auto

Next project