VR Ohjus Runs on Data and Design
Embark on a journey towards better commuter train service. Read about how combining data and design helped co-create and further develop Ohjus, a situational awareness system of the Finnish railroad company, VR. Now, in our third blogpost on the data & design topic, we share the best practices of how these two areas can inspire and support each other for delivering great customer experiences.
On average, two trains leave Helsinki train station every minute during the rush hour. The commuter traffic operations center manages disturbances caused by railroad infrastructure problems, technical problems with trains, train operators or issues related to staff availability, for example.
To support VR’s operations center personnel in their fast-paced decision-making, we helped to develop Ohjus, a system that provides real-time situational awareness for different user groups, automates simple tasks and communication, and supports data-driven decision-making. Both data and design are equally important for helping the personnel react to issues that require attention. Now we get to hear the experiences of our Lead Service Designer Aino Kuru and Data Engineer Jari Hast.
Started by vision, fueled with data and design
"Here we had a wonderful chance to first figure out the desired future, then the steps on how to get there and then continue to the implementation phase." -Aino
The collaboration with VR started with a vision project, where our multidisciplinary team explored both the user and business needs, followed by co-creating a vision and roadmap in order to understand where VR wants to be in the future and how to get there. Storytelling was used to communicate and validate the vision with stakeholders all the way from management to operative personnel. With a validated vision and a roadmap, we continued to the development phase.
"To me this was the first long project where I got to work as a Service Designer from the early beginning until the MVP launch and to the continuous development phase with developers without any breaks or pauses. It was very valuable since I got to dig deep into the domain, got to know both the users and other internal stakeholders and really understand their daily work, pain points and success factors. I got a nickname “train whisperer” and I’m truly proud of it." -Aino
Development phase started with converting the user needs to user stories and prioritizing them in order to form a development backlog.
"It should be kept in mind that each user story may require several technical features and their combinations, which need to be discussed together with developers and data engineers. In agile projects constant communication between design, tech and data people is a must and both the team and key internal stakeholders must be ready to re-examine the priorities when there are e.g. unexpected delays with third parties." -Aino
Staying on the right track
"Even though we are not novices when it comes to expert systems, the breadth and complexity of the domain probably surprised all of us. There’s so much detail in how the trains and the related personnel are operated. As an anecdote, I have never produced this amount of documentation and code comments in my life." -Jari
Feedback is one of the most important inputs in a user-centered project like Ohjus. The ideas from end users are discussed with them in order to understand the “why” and the need behind them. Next, these needs are refined in brainstorms between designers and developers alike. Once the team has come up with a proposition or two on how to fulfill the specific need, the solutions are tested with the end users and iterated until all parties are satisfied. This way everyone, including the backend-focused engineers, have contributed significantly also in designing Ohjus. As the domain is both complex and multifunctional, it’s important that the UI communicates all the possibilities and shortcomings of the data as transparently as possible.
"As we recognized the amount of edge cases and situations where the data cannot express the reality too well, we adopted a principle of "first, do no harm". That is, we try our hardest to recognize inconsistencies and error states. Our UI is very vocal when we think the data is stale or otherwise not correct. Especially in figuring out how to best handle these cases, it is paramount that everyone on the team and the users are involved in these discussions." -Jari
In a data intensive project such as Ohjus, there are also many situations where the data engineers’ personal contact with the users is crucial. For example, complex topics, such as automating decision making rules for commuter traffic, require a holistic approach. To get the rules right, we need to understand the domain logic as well as the limitations and possibilities imposed by the data available. Building a rule set like this requires close collaboration between the developer/data-engineer and the user who is the domain expert.
"I’m more a people person than a tech person and I learned a lot when listening e.g. the discussions that Jari had with our users. It’s both interesting and important to understand how your colleagues from other competences see the world and how they think. When I couldn’t contribute to the technical solutions I made sure that the relationships with our users evolved and deepened to support the continuous feedback loop." -Aino
From the start, the team has had a clear focus on good customer service. Responding to feedback is swift and feature requests are immediately taken into consideration.
"Our users’ jobs can get hectic at times and there are many situations where decisions have to be made almost instantly. Since new software always introduces at least some cognitive overhead, it is not given that everyone uses our new tool just because it’s available. One of our ways to tackle this is strive for excellent customer service and implement new requested features as much as we can. This has been a good way to get users more invested in the project." -Jari
Agile development is based on communication
In a typical setting, a service designer is the one who first dives deep into the business domain and the needs of the users. Service designer enables developers by providing the relevant and condensed bits of information upon which the developer can build the technical solution effectively. In the Ohjus project however, these roles have somewhat fluctuated. It's not unusual for the developers to explore a new topic by involving relevant stakeholders and figuring the context out. In these cases, the service designer links the new findings to the bigger picture and possible future endeavours. This dynamic way of working has been rewarding for the whole team, and has had a positive impact on getting feedback from the end users — direct communication strengthens relationships.
"The best part about consulting for me is when I get to talk to experts in their respective domain. In this project I got to do exactly that. I must have spent tens of hours discussing and problem solving different aspects of operating the train traffic." -Jari
"In the end, Ohjus is not rocket science; it is a result of top professionals working closely together in inspiring ways." - Aino
This is what future-proofed and connected companies are built upon.
Previously on this topic: Future is where design meets data and Experiences of Data-driven Design from Futurice Exponential
- Aino KuruLead Service Designer
- Jari HastData Engineer, Backend Developer