Applying the Least Work Principle

Developing a great, user-friendly, innovative product is often the heart of building a successful high-potential startup. But, as the team blazes new trails, they must successfully sift through user feedback to nail the design. The Least Work Principle is one of my tools for interpreting what users mean instead of just what they seem to be saying.

It is always a good idea to engage your future customers in the design of your innovative new solution to one of their pain points. User input and feedback are invaluable as you strive to make that product as easy to use as possible, especially if your solution involves software.

However, here is the potential pitfall. Almost every new product that people engage with operates in a larger context. It is a tool to get something done. And therefore, when you are breaking new ground, you cannot always take what your potential future users say at face value. 

When you ask potential users of your future product what they want, the feedback you get will almost always include a desire for the tool to be “easy,” a universally-valued design goal. At a high level, it makes sense. It is a rare scenario where the user wants to be forced to do more work than is absolutely necessary to accomplish their objective. I think of this as the Least Work Principle because striving to minimize the amount of work the user must do will usually result in an easy, low-burden workflow.

So, what makes something easy? In most cases, fewer clicks, less manual input, and consolidating information into a single all-singing, all-dancing interface seem like good ideas to make something easy – and at one level, they are. Furthermore, many other design aspects contribute to the feeling of “easy,” including careful layout, intuitive workflows, clear and consistent use of well-recognized design patterns, and many other elements that I will not attempt to detail in the scope of less than a few thousand words. And, yet, these details are not enough.

Herein lie some of the keys to applying the Least Work Principle to achieve a user perception of easy:

Choose the right relevant context.

Think about the whole end-to-end process from the users’ point of view. Consider what comes before and after the part that your tool is involved in. 

Recently we were designing a new workflow for a high-priority clinical use case for our medical device software. The goal was to broaden the number of ECG-monitored patients in a hospital using an inexpensive wearable ECG patch to enable AI-eye-in-the-sky support of stretched clinical teams to identify potentially deteriorating patients. Because this tool is intended to support the overburdened nurses, our goal was to make adding continuous automated monitoring as simple as possible. 

As we were developing our product feature set, several people told us, “Nurses will never be willing to add the patient’s name manually.” Listening to that feedback, you might be inclined just to leave out the ability and requirement to add the patient’s name in addition to their unique identifying number altogether. That would make it easier, right? By minimizing clicks and manual data entry? However, suppose you consider the larger context in which the tool is used to flag deteriorating patients, when the tool highlights a concerning trend. In that case, the nurses must quickly determine who the patient is to act on it. Now the right question comes into focus. When the tool does its primary job and highlights a concerning patient trend, that is when it must provide the critical information required for the team to quickly and easily engage to assess and proactively address the emerging problem.

When gathering and translating feedback into a well-crafted solution, remember to consider the whole relevant context from the user’s point of view, not just the piece of it automated or enabled by your tool and not just your tool’s internal workflow.

Avoid moving the work around.

One way to leverage thinking about the right relevant context is to use that broader point of view to ensure you are not just moving the work around. Remember that the least work principle is ultimately about optimizing the entire user experience of the workflow. If you make something simple within your application but add complexity outside it, that will not be judged to be easier and may even be enough to cause someone to decide it is not worth it.

To continue with our example, if the patient deterioration early warning system only provides clinicians with an awkward 9-digit unique identifying number because you did not ask the nurses to add the patient’s name up front as well, you may force users to invent handwritten lists on notepads or require them to search for the identifying information they need in yet another application. In other words, by minimizing the work in the tool, you may actually be creating far more burden than just allowing them to put the information where it is most usefully stored within your application. Essentially, you are moving the work around – and not in a good way- optimizing for the least work locally, while creating more work and stress globally.

When gathering user input, listen not just to the user’s words but to the underlying goal(s) they are trying to achieve.

Using open-ended questions, dig carefully to understand the full scope of future users’ pain points and the nature of the problem they are attempting to solve. Since users are often not particularly good at envisioning what an excellent solution would be, as a product developer, you must interpret your user feedback wisely to recognize their goal and make sure their suggestions address that goal.

For a creative and visionary product development team, this deeper understanding of the user’s context, goals, and unmet needs flows into an emerging vision of the future state in which these problems are solved with the yet-to-be-fully-designed new product. Once the general outline of the solution is validated (given that problem, what if you had a tool that could give you x, y, and z? Would that help solve it?), then all the details of the specific design need to be worked out. Be careful not to over-index on comments about extra clicks or the tortures of having to sign in, and focus on creating value for the user that makes these burdens worth it as you seek to make the whole of their experience better using the least work overall.

When startup development teams are figuring out their product design, they must consider the larger context of when, how, and by whom their tool will be used. Many techniques can be helpful in this process. However, I find that thoughtfully applying the least work principle within the user’s larger context helps avoid the trap of moving the work around and allows you to carefully interpret the input you gather often yields good and sometimes not obvious insights to successfully address some unmet user needs successfully.