Developing software applications that customers love
DNV is embracing a new, better way of developing software applications through user experience (UX) design that gets end-users involved in the design process every step of the way.
For this blog post I am delighted to introduce you to our guest blogger Mihaela Negura. Mihaela, who is based in our Mechanicsburg, Pennsylvania office, is the UX Lead for DNV’s Pipeline Solutions Portfolio. Previously, Mihaela worked as the development manager for our Synergi Gas and Synergi Liquid products, leading the development and delivery of multiple product releases.
Here, Mihaela describes a new approach to developing software applications that involves collaborating with end-users to design software applications that customers will love.
Developing Synergi Pipeline regulator Station application
How to design pipeline hydraulic and integrity applications that customers will love
DNV is developing software applications in a new, better way through partnering with end-users to design applications that customers will love.
The old way of developing software applications
What was the old way of planning for and developing software? The end-user would request new functionality. The product manager would ask several questions and start working on a requirements document. That requirements document would detail the required functionality, everything the new functionality needed, new editors to be created with all the buttons and input fields. Then some analysis, like a pipeline hydraulic steady-state analysis or a pipeline risk analysis. And of course, the product manager would think of a way of showing results, like a chart or a report or a combination of these. This document would be handed over to the development team, who would work in an Agile way on this new functionality.
But this requirements document would be functionality based, and it would contain almost nothing about the user. Why does the user need this? How would this new functionality help the user do the job? How is it different than what the user does today? And then there were some other some big unknowns, like when would this functionality be finished? Is this something the user actually needs, and how usable is it? Did we understand what the user requested? This way of working almost always results in over-budget and late projects.
Now, full disclosure here; we always had a very good partnership with our clients, and they already love the products we offer. But I believe we can do much better.
How does this compare with building a house?
Let’s say you hire a building company to build you a house, and you are on a strict budget, and you need to move in within three months. You talk with your contractor about how many rooms you want and give general specifications about what you want. The contractor starts building what they think you want but doesn’t check in with you to make sure they are correct in their assumptions. Unfortunately, the time comes when you have to move into your new house, but you find out that because of unexpected circumstances, it is not quite finished and it’s already over budget.
The new, better way of developing software applications
Well, there is a much better way of working on new software applications. And that is getting the end-user involved every step of the way. We start with user research where the User Experience person in the team, along with the product manager and other stakeholders have extensive discussions with the user. They ask questions and try to understand the jobs-to-be-done. How do they do the jobs today? What works and what doesn’t work with their current process? What is missing from the way they are doing the job today?
All these are being mapped in what strategyzer.com calls a “Value Proposition Map” where the “jobs-to-be-done” are listed, along with the pains and the gains. It identifies what is important to the customer and require a very deep conversation about what they really need. The “jobs-to-be-done,” gains and pains are further mapped in the “Value Proposition” canvas. This is where the new application is clearly defined, and it will explain how it will create gains and relieve pains for the customers.
Then we take the “jobs-to-be-done” and use “user story mapping” developed by Jeff Patton in his book “User Story Mapping: Discover the Whole Story, Build the Right Product.” In this, we take each of the jobs and write the user’s actions to complete the job. The actions will then map into the “things” that we have to develop for this new application. But there is another very important aspect to all this. We really must consider the first version of this application, or what some call the Minimum Viable Product (or MVP). In other words, what is the minimum set of functionalities that this application needs to have to still be usable? This is something you discover in the discussions you are having with the end-users.
New development process for Regulator Station application
Let’s take a concrete example and see how we used this new way of developing a successful software application. Here, at DNV we recently started working on a Regulator Station application where we are failing closed regulator stations to see how that impacts customers downstream. The results of this application can be consumed by Synergi Pipeline in Regulator Station Risk calculations. We started talking with our customers to see how they are doing this type of analysis today, why do they have to do it, and what pain points do they encounter in their current process. We used this information to create the Value Proposition Canvas, where we listed the “jobs-to-be-done” along with the pains and gains.
We then took each of the “jobs-to-be-done” and created a “user story map,” where we listed the activities the user would have to take to complete that job. This drives the functionalities that we must develop for each activity. The next step for us is to prioritize and get the minimum set of functionalities for each of these activities to form the MVP.
So, let’s look at a sample so you can see what I’m talking about. [Please note, the depicted functionalities in the sample are for illustration purposes only.]
Job-to-be-done: Run regulator station fail closed analysis
From here, we prioritize the functionality in a “release plan,” and you can easily see that we will have a functional application for the first MVP. If we add a “wow factor,” then we have a Minimum Awesome Product or MAP.
Test and iterate
Well, in practice, it’s not this simple, but you get the idea. The next step would be to create a prototype for this MVP and test it with the user. This would answer the questions:
- Will this application help the user do the job?
Developing applications customers will love - Will this first release offer enough functionality for the users to do their job?
- Are there any usability issues when using the interactive prototype?
The workflow is also important to consider here. One step should logically follow the previous one, so users do not get confused or frustrated. Automatization should also be considered for repetitive and sequential steps.
This design process will go through a set of iterations until everybody is happy with the prototype, and developers can finally start developing the application. But the artifacts we produce with this process are not set in stone. They are breathing and living artifacts that help with the discussion between designers, product managers, engineers, stakeholders, and end-users. These artifacts are not documents; they are more like discussion vehicles that help everybody get a clear understanding of what is to be done and how to get there.
So, this is the first MVP. Future releases can then include future enhancements to those steps, but you must test and validate with the users first.
How does this new process compare with a better way of building a house?
Let’s get back to our house now and see how we can use this new process to help you move into your new house in three months without going over budget. Well, before starting working on the house, the contractor talks with you and tries to understand what your needs are. Because the time and budget are limited, the contractor will work on the essentials first, like the walls and the roof. Once something is done, he will show you to make sure you’re getting what you need. You will often visit the house to see how it looks and if any changes are to be made. Because he prioritized the essential elements or the minimum requirements, the house is ready within three months and is within the budget. After you move in, you live there for a while; then you have a much better idea of what kind of improvements you want to make.
Get involved
DNV needs your help to develop applications you will love to use. We want to know how you do your job, what works, and what doesn’t work for you. We are looking for volunteers to assist in design sessions, usability tests, prototype reviews, ideation sessions, and more. Please consider being our partners in this process and sign-up for future UX activities at https://dnvgl.com/uxsurvey.
Author: Mihaela Negura
10/6/2020 1:36:47 PM