The Three Types of Work
There are many factors that go into determining whether or not a product will be successful, but a key one is enabling potential customers to extract value quickly. When customers use a product, they do so with a purpose. They might need to accomplish a task, have a little fun, or learn something new. Whatever the reason, each particular product offers something (or believes it offers something) that provides value to that customer.
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? Probably not.
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, this 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 the latest trending 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.
Not all domains are created equal, though. Sure, using a hammer is very straightforward. Flying an airplane, though, is not. Managing a nuclear power plant is even more complex. Creating a great product requires a deep understanding of the domain, which requires not only talking with users, but talking with the right users. For simple domains, most customers are created equal, and if not, their differences need to be accommodated in the product. For complex domains, though, you should aim to talk with experts as they have a deep understanding of the domain and all its complexities. You wouldn’t want to design an airplane cockpit based on some amateur pilot’s understanding of the principles of flight.
A system will not be successful if you don’t 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 (like the hammer). 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.
Data entry isn’t the only place where designers ask too much of customers. Another is providing data to customers but asking them to interpret the data. 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 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. The design team should provide the numbers and a visualization that makes the pattern in the data evident 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 will interfere with their domain work. 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. System work comes in many forms, and can be a key driver of complaints of your product. Requiring your customer to complete a lengthy registration process before using your product is asking them to do system work.
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.
One egregious form of system work is when the product team expects the customer to do the design work for them. When the product expects the customer to create a dashboard, or modify the homepage, or define the colors in a chart, they are forcing the customer to do system work. While it may seem like empowering the customer, in reality the product team has abdicated the responsibility of design. Not only is the product team interfering with domain work in these cases, they may actually make it more difficult to complete the work, since customers are unlikely to design the system in an effective way (given how difficult it is to design good products).
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.
