Details

Client

Stena Line

Role

UX Design, UI Design

Year

2019-2020

Summary

Stena Line's vision is to be the first cognitive ferry company in the world. To accomplish this, they launched a digital transformation project and hired me as the UX Lead to help the team bring that vision into reality.

As a part of the Trade Management Team, the main project I worked on was a web app called Nemo - an admin dashboard to analyze and optimize departure capacity and pricing.

Problem

The Trade Management process aims to optimize the different capacities in terms of revenue and costs. With more than 28.000 departures annually and more than 1.000.000 price points (for Travel only), Stena Line is dependent on automation and good processes to reach their goals. Trade Managers need better tools (other than Excel, PP & email, etc.) to do the work and collaborate across the company.

Solution

Stena Line's vision with Trade Management is to make this process easier and more profitable by offering new cognitive tools. My role was to help the team develop products that support Trade Managers' processes and enhance them. This resulted in several products put together under the same roof, a cloud-based application called Nemo. 

Timetable - Schedule and managing departures and ships.

Customer Allotment - Efficient handling of block bookings.

Capacity - Actionable shared capacity view between freight and travel.

Pricing - Dynamic Travel Pricing

Forecast - KPIs and automated forecast for travel and freight, to enhance optimization by improved decision making.

Research methods

Information Architecture

User interviews

Prototype testing

Persona

Impact Mapping

Users

Nemo's key users are mainly Trade Managers and Trade Optimisers. The purpose of the application is to have a common and unified Actionable Shared Capacity View for the departures to achieve the common goal, optimizing the sailings for increased profitability.

Impact Mapping showed us that we could categorize the users into 4 types based on behaviors and needs:

The lookout

Works tactically and monitors the status of the sailings weeks or months before departures. Needs proper forecasts. Events, trends, and KPIs are an important input to be able to identify good or bad sailings. Struggles with not being able to identify bad sailings in time in order to maximize the profits.

The operator

Works operative and takes actions to optimize the sailings. Solves bottlenecks and negotiates ship capacity between freight and travel. Adjusting the price levels can be a great part of the job. The actions will have a great impact on how the profitability. Struggles with not knowing exactly which action will have the best impact on profitability.

The navigator

Works strategically and is responsible for the gross profit for the route. Monitors target to budget on a monthly and yearly basis. Needs to make sure everything is up and running for departures months ahead. Spends time on optimizing the departure time table. Decides the price levels once a year, which takes up a lot of their time—struggles with not having full control of the current price levels, from overview down to the details.

The concerned

A person who unwillingly needs to spend a lot of time checking for errors to find them before the customers do. Someone who would rather spend time on other activities but feels is hindered by not having total control of what customers face.

User flow

UI elements

When I started working on Nemo, I learned that there had been at least 3 designers that briefly jumped in and out before me, and for the year or so, the team had been building new features and fixes without a designer on the team. So, there was a lot of inconsistency and confusion UX that needed to be mended. Other teams in the house were also working on their own UI solutions to solve similar issues... So, not only different parts of Nemo looked like different applications, none of the internal applications of Stena Line looked like a Stena Line product... That got me asking questions like, "how should a Stena Line internal application look and feel like?" "what type of 

Looking at the task at hand and the tasks ahead, we decided to build our own design system to put standards in place, eliminate inconsistencies, and have a common design language for all internal applications. This way, we would cut costs, speed up the software development (in the long run), share assets and code between teams, bring designers and developers closer, and bring many teams at Stena Line closer to each other.

This initiative gave birth to the Lighthouse Design System, created and maintained by a couple of UX & UI designers and Front-end Developers.

Visuals

Nemo was a big project. A lot of it was repetitive tables and a lot of data to display. While we were planning and designing new features, we were also translating their (very) old system into our modern web app. The challenge was not only to make it easier and prettier but to figure out how to make it smarter.

Prototyping

I created a prototype for every feature and presented it to our users and stakeholders on bi-weekly meetings. At these meetings, I could gather feedback and questions to iterate and improve the prototype before a feature was signed-off by the PO for handover to the developers.

In addition to scheduled meetings, I sometimes would record and put together demo videos with the prototypes and show them to our users to get feedback sooner. I also send links to interactive prototypes (InVision) to click around and get a feel for the features.

We worked on some of the features' finer details, such as micro-interactions and animations, together with the developers. It was easier and faster to test these with code than to spend time on design/prototyping tools.

Implementation

I was working on Nemo and Lighthouse Design System simultaneously. The developers were also implementing new features and simultaneously replacing old code with new components from the react-library.  Meanwhile, another team of developers was maintaining and updating the components to match the design system. This somewhat chaotic situation made us very agile and efficient - but at the same time, there was a lot that needed fixing that we couldn't foresee.

If we ever wanted to implement the design system to all products and all parts of the products, we needed to adapt to a "move fast and break things" mindset. This basically meant that we implemented the design system, and a developer could work in a separate feature branch first. We tested the UI and gathered all the issues, and created tasks for each bug and improvement. We then sorted and prioritized what could be good enough and what had to be done before a beta release.

Continuous delivery and prioritization of the tasks allowed us to release features and design solutions in smaller chunks and allowed us to test and gather feedback to iterate and improve continuously.

UI issues and suggested solutions. I used an artboard for each problem/solution and created a task in the backlog for all of them.

Learnings

Simplify complexity

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam dictum tincidunt magna ut tristique. Fusce mattis aliquet tellus, et malesuada metus tincidunt in. Nunc velit metus, vehicula in ligula at, gravida sollicitudin odio. Ut a vehicula libero, sed accumsan tortor. Morbi sit amet fermentum lectus.

Collobration is the key

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam dictum tincidunt magna ut tristique. Fusce mattis aliquet tellus, et malesuada metus tincidunt in. Nunc velit metus, vehicula in ligula at, gravida sollicitudin odio. Ut a vehicula libero, sed accumsan tortor. Morbi sit amet fermentum lectus.

Trust empowers people

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam dictum tincidunt magna ut tristique. Fusce mattis aliquet tellus, et malesuada metus tincidunt in. Nunc velit metus, vehicula in ligula at, gravida sollicitudin odio. Ut a vehicula libero, sed accumsan tortor. Morbi sit amet fermentum lectus.

Done is better than perfect

With a big (and continuously growing) backlog, there's always something to do and something to improve. With my team at Stena Line, we understood what we could build and release now and what we can add and improve on later. For bigger features (epics), It's crucial to have a process to understand and narrow down the scope to what could be an MVP and then split up the rest into sprints/continuous delivery releases.