Terminal App
UI/UX Designer
App for Value products at terminal
Team member 1 of 11
Crossfunctional team work
Timespan: 9 months
Brief, MVP (app and Webb)
The app is a tool for terminal workers at all terminals across Sweden. It should:
• replace any paper and desktop depending way of working.
• Specifically handle high value object with high security
• Provide flexible and fast interaction that cater for the user needs during an active workday on the floor.
• Be compatible with the correct expressions and UX copy. and should also provide suggestions or new expressions.
In addition a web-based tool was also designed to support specific features. This was a project with strong focus on early testing, trial and error and supporting each others roles to make sure we will lay a good foundation to iterate from in the future.
Challenges
• Short deadline
- The project had been paused and resumed and I came into a phase where some aspects were set but not yet tested.
• Component/design system depth
The project was lacking connection to any design system and had no components made.
• Low UX maturity - heavy on tech
There was a need to advocate for the users and also to do qualitative testing to make sure we we’re building the right thing. Even if the architecture of back-end was somewhat set - there was still huge possibilities to meet the users front-end.
Process description
Test prototypes early
- get to know users
I started visiting a terminal along with a coworker who took notes when I tested prototypes. I needed to learn as much as possible in a short amount of time. Field research had been made and an architecture foundation for back-end was made.
However, when we started testing pitfalls, errors and undefined use cases was discovered. After evaluation and consideration, some usecases was added to the scope.
Ways of working
• Qualitative testing (at terminal)
• Quantitative testing (Maze.co)
• Workshops
• Demos for stakeholders
• User journeys and personas (briefly due to time).
Field research had been made previously and mapped in user journeys with pictures of paper flows.
Find a way to present progress and share insights. Teamwork.
Everything that affects the scope must be proven necessary. It became crucial to have a clear way of presenting and advocating for the users needs. But also stay humble for budget and deadline. This meant a close teamwork with all team members and especially the Product Owner. And also meant that I had to ask for help to investigate what could actually be done in the organization.
The users
The users (Terminal workers across Sweden). Has in general very high knowledge in the work procedures and high competence. They we’re specifically chosen to handle value and high security objects. Since the app will replace the paper-based way of working. I needed to understand how easy/hard the digital transition might become.
We asked terminal workers at Stockholms biggest terminal and also sent out forms to other terminals across Sweden.
General App usage
-
Info icon
What should we know about the services you provide? Better descriptions result in more sales.
-
Consistent placement of menu
What should we know about the services you provide? Better descriptions result in more sales.
-
Empty states with info
What should we know about the services you provide? Better descriptions result in more sales.
-
Highlight value and big press surfaces
“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.
A/B tests & speed
Scenario: The user receives goods from the driver at the terminal. When it’s offloaded the terminal worker should scan (with phone or handscanner) each object to confirm. If anything is missing or damaged. It’s needs to be reported right away. The driver awaits the control, and the way of warking requires speed and efficency.
-
A - Report per item
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.
-
B - Report in bulk
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.
Conclusion
After letting the users test both. Where they clearly struggled a bit with the B-test before they understood how to report. We had an open discussion. I asked which one they prefered, and then I followed up with which one would work best under time-preassure. Here the users had to help us understand if they prefer a clear pattern without having to learn (option A). Or option B where they would have to learn the first time. But since they wouldn’t have report per item but could report in bulk they could earn time and have less interaction points.
The B test won in efficiency which in this workflow is highly valued since it’s an interaction and confirmation process while the driver is waiting to leave. However, we don’t want the user to get stuck if they don’t understand. Therefore we added instruction in the top but also under the info icon. This is one example of how important it was to not presume anything and to keep weighing what is valued most.
Flexibility and building a tool
After visiting the terminal and talking to the users. We learned that they prefer to work in different ways. In the first wire frames only one specific way was catered for. But with the new findings. It was decided to cater for three different ways. Below are two examples.
Items first
Maybe you want to turn a hobby into something more. Maybe you want to launch a business.
Loadcarrier first
Maybe you want to turn a hobby into something more. Or maybe you have a creative project to share with the world.
-
The value of working crossfuntional
What should we know about the services you provide? Better descriptions result in more sales.
-
UX copy: PB to Postbil
What should we know about the services you provide? Better descriptions result in more sales.
-
Findings
What should we know about the services you provide? Better descriptions result in more sales.
-
Design from skratch with no design library
Description goes here
Maze
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.
