A product like a hammer is straightforward. It's potential value is immediately obvious. There is little mystery to it, and it can be picked up and used immediately. When we design software products, however, things become a little more convoluted. Most products start out with some idea of the expected value that is to be provided (although not as many as we might hope). Even if the value is obvious, do we allow customers to extract that value right away?
While we want our customers to get to work, and often put them to work using our product, all work is not created equal. There are actually three different types of work that we might assign to our customers when they use our products. To deliver good products, it is essential to understand these different types of work and what they help customers accomplish.
Domain Work
When we think of customers using our products, domain work is the type of work that comes to mind. This is the customer accomplishing the tasks they set out to. Whether you created an app that allows customers to book a flight, designed an addictive video game, or created the latest iteration of a good old fashioned hammer, seeing a customer have success is a great feeling. They purchased your product for a reason, and your customers were able to find and extract some value.
A system will only be successful if you support the domain work properly. Most of the focus should be placed here. But getting this correct doesn't guarantee a good product; for that you also need to make sure the other two levels are taken care of.
Support Work
This is the first area where software products start diverging from traditional products. Whereas a hammer requires absolutely no support, many products require some support work to allow customers to operate effectively. This type of work is not essential in all software products, but does come into play quite often. Need to create user privileges for your enterprise software? That’s support work. Want to set some standard flight options for fare alerts? That’s also support work.
Support work is not what allows the customer to extract value (the domain work) but when applied correctly helps make the domain work easier to accomplish. It is often as essential as the domain work, especially as domain complexity increases.
There is one key area of support work that is often not considered, but essential to get right - data entry. For many software products, there is no value without data entry. Think of any enterprise system, and the key will be the data available (and the data collected; they aren't always the same, but that's another story). For many products, though, data entry is often left to the customer. The potential value of the product is immense, but it assumes that the customer will enter in the necessary data to drive that value.
But people don't work that way. People want to get value. They may do a little bit of work, but once the effort required exceeds the value, people will stop using the product. This is a fatal flaw of many products. Where possible, the system should collect and report the data for the customer. This is where automation and the internet of things come in handy. There are myriad ways to collect data for the customers. Finding the right way to automatically enter data for your customers will pay off in the long run.
It's not enough to just present customers the data and ask them to interpret it / figure out its meaning. This has been a hallmark of ‘Enterprise’ systems for a long time. While providing data is good, designing the product so that customers don't have to make real-time data computations and interpretations would be even better. The customers should not be given a set of numbers in a table and asked to come to some conclusion. This is asking them to do a lot of support work, and it's a task that the system can do faster and with fewer errors (doing this correctly requires understanding the domain work enough to present the data in the right way, but that's part of the challenge already).
The design team should provide the numbers alongside a representation that makes the pattern in the data evident, the logic behind the pattern, and the decision to make clear. That is what makes good design. If not, you are asking the customer to do too much support work, which increases the likelihood that you interfere with their domain work, either by introducing errors or simply by occupying too much of your customer’s time. When this happens, customers will start to abandon the product.
System Work
The last type of work that you might ask your customers to do is system work. In this work, the customer is actually doing work to manage the product itself, rather than anything that will help them extract value. Requiring your customer to complete a registration process before using your product is asking them to do system work. System work comes in many forms, and can be a key driver of both complaints of and delights in your product.
Certainly, there is some use for system work. You likely do need customers to fill out some information, but too much gets in the way. Security is another form of system work. It is absolutely essential, but the more difficult you make it, ironically, the more frustrating it is for the customer.
Another form of system work that seems to be requested frequently? Personalization. Most software systems these days seem to want to include some way for the customer to add their own personal touches to the product, usually expecting to improve the emotional impact of the product. While this may have some positive impact on the overall Customer Experience, this often distracts from the domain work. The problems come when the product team decides to focus more on this aspect to make the system ‘fun’ at the expense of supporting the actual domain work.
Putting it all together
It would be nice if there were some simple rule to determine how much time you should spend on each type of work, but product design is never that straightforward. Different products will require different levels of support at each level. Some products may end up being mostly domain work while others require heavy investments in support or system work. Where possible, it’s nice to find ways to eliminate support and system work. And yet, there is value to be found in these areas. People like some level of personalization in their products. Security is essential. However these can be streamlined and enjoyable they should be made so. The key is to make sure that the system and support work are not getting in the way of the domain work. Anything that interferes with domain work prevents a customer from extracting value. Once you lose that, you start losing customers. A failed product is sure to follow.