Daniel Ritzenthaler

Writing a Good Objective

A good objective or goal is a combination of a specific form of progress, a direction for the progress, and an expectation of change.

For example…

We intend to reduce the amount of time it takes to write a medical note so that our clinical staff is no longer working into the evening.

Time spent writing medical notes is what we can influence through the design of our software. We want to reduce the time spent. When we do that enough, we believe our clinical staff will stop writing notes in the evening and spend more time with their friends and family.

We can be specific about our work while contributing to a big change.

Friction From Fear

The struggle to write a good objective or goal comes form one of two places:

  1. We can’t think of anything specific to improve and get stuck.
  2. We think of too many specific things to improve and get stuck.

These are similar forms of the same fear:

  1. Our idea is too big to be measured in a specific way and we’re scared to break it down.
  2. Our idea will work by improving several specific things simultaneously and we’re scared to pick one.

Neither of these fears are true.

Fight the urge to combine and merge forms of progress into abstract concepts. Fight the urge to keep abstract concepts intact.

Working with abstract concepts doesn’t make us more strategic. It doesn’t mean we understand a bigger picture. It doesn’t mean we’re doing something more valuable.

It means we’re being vague. It means we’re unable to measure progress. It means we should expect low quality output.

Jumping to Solutions

It's the quickest way to get in trouble.

A good objective should be agnostic to a solution. It should give a strong feedback loop without dictating a path. It can absorb more variation of planning and better adapt to new information.

Even though we can’t start with a solution, we need to be fast. Work on making progress — the big-bang change will reveal itself.

We can’t wait to research a solution that guarantees our desired change. We can’t wait to validate a “known” solution. That doesn’t mean we should take a commit on a loosely studied solution.

Instead we can immediately get to work in ways that make progress. It doesn’t have to cause a big change. We can make it small. We can measure a response. We can amplify if it works. We can dampen if it doesn’t work. We can make bigger bets as we get more feedback.

We may not see a beneficial change for a while, but if we’re seeing the right progress we can assume we’re on the right path. We can explore. We can experiment. We can learn.

We don’t need a holistic solution to start. We need to know what progress to make and signs of success.

Write a good objective and get to work.

The Problem with Problems

Don’t talk about problems (or solutions). Instead, talk about progress. Only then can we be precise without dictating implementation details.

Interface Design Values

When designing interfaces, we value clarity, efficiency, consistency, and beauty. Designing interfaces with these values in balance is possible. Unfortunately, it’s time and resource intensive. To get things done, we make sacrifices.