Based on empirical research, many IT projects don’t seem to be a success from a business perspective. Goals were not achieved, budgets were exceeded, user needs were not met and a healthy ROI was missing. In my opinion, that’s not surprising: with an average project the starting points are more vague than they appear. In our experience, value driven design is a powerful solution and I will show you how to do it with a real-life example.
We find that a lot of projects are started from a general sense of necessity or an informed decision about the general direction. For instance:
“We need a portal in order to combine our products into one environment.”
The informed decision about the general direction could be that this client wants its clients (the buyers) to use more of their products and therefore boost sales. The general sense of necessity could be that the buyers or users need the features that those other products offer.
With this kind of starting point it is hard to decide what the focus of the design should be. Either the wrong assumptions are made about why buyers and users value the product. Or there is no focus and the project team try to address everything. Without the clarity of producer values, this will not only lead to endless discussions. It will probably cause the project to overshoot its deadlines as well. And the biggest risk of all: there’s a real chance that the product will not deliver the (general) results that it was expected to do.
The risks above can easily be averted by being clear on why the product is valuable to its producer. In fact, it’s not hard to imagine multiple sound and concrete business reasons to design and develop the portal I mentioned. In value driven design, these are called “producer values”*.
Producer values are not limited to portals. However, this real-life case that we worked on, a portal that should act as a “catch all” for all the products of our client, makes for a great example. During the discussions we had with their CEO, CTO and CFO, a fundamentally different view of the goals of the portal came to light.
Possible producer values for the portal mentioned above that we talked about were:
In practice, clients are interested in the value of all of these potential results. But as long as they are general senses of necessity it will be hard to make decisions during the project. Which in turn will lead to a solution that is not as valuable as it could be.
A very simple way of looking at this could be: which of these 6 solutions is the most valuable? Which of these will get you the most money? A bit more sensible would be: which of these values will give you the “biggest bang for your buck” i.e. the most money for the least expense? (By the way, not every business value is directly monetary.)
Why is this important? Because it will structure your project and project costs. Let’s have a look at each scenario:
You will need to design a portal with access to your individual products with 1 solution for your recurring enabling solutions. You already have several in place, so you can pick the one that fits your requirements best. That solution will require a bit of tweaking.
You will have to design a portal with access to your individual products. And you will need to “design” a target IT architecture, that you have to implement. For an MVP, this could mean that users won’t notice a thing.
You will need to find out which user tasks could be switched to self-service and what impact each of these tasks has on the operating costs. Then you do the research with your users to see if they agree with you. The combination of this work will show you which user tasks can be switched, and you can do the math on the savings that you expect from that. The design can focus on enabling the user to service themselves.
In this scenario you have to find out which cross sell options are most likely and most beneficial to you. You will then need to design a portal or environment in which your products support each other. And in which you support cross sales. In the previous scenarios you don’t necessarily have to consider different pricing. In this scenario, different pricing to encourage cross selling is definitely something that can help you achieve that goal.
If your portal is to be more appealing because you combine products that users use anyway, then it is important to see which products are used in what way. And how you can combine the products in that one portal to support work processes.
Adding functionality that should substantially lift your bottom line is an investment in design, development and marketing. With other specialists chiming in as well. An entirely different and riskier prospect altogether.
Any one of the scenarios above means doing different things to get different returns. Most of them mean that every design brief is different from the next. And that’s what matters to us designers. We will be making different designs for different producer values.
Good designers will probably make good things even without clarity. Good things that are even relevant, perhaps. Indeed: perhaps, and: maybe. Many directions can be okay if your goals aren’t too clear. Do you really want to have a solid business case with a great ROI? Then start your project with as much clarity about the producer values as you will want to see in your project reports.
To be clear, I’m not advocating taking your client through a business strategy project. We are designers and not business strategists. However, we should be able to ask them the right questions. How they come up with the answers is their business.
If your client can tell you, in quantitative terms, why she is paying money to have a digital product developed, then that will drive decisions in your design. Which you will need to get the results that your client is looking for. And sometimes, you don’t need any design at all.
* “Producer values” are business goals, but different to “buyer values”, “partner values” and “supplier values” (that are all business goals as well) and of course “user values”.
You might also like:
An introduction to value driven design
Buyer values in the design process: when 'why' matters more than 'what'
A lot of user stories are not user stories
Upgrading from feature driven to value driven development