Product Principles
Product principles complement the product vision by stating the values and beliefs intended to inform the many product decisions we have to make.
Don’t make them think
Simplicity is not simple. Products that are easy and intuitive to use often get the right balance of simplicity. Healthcare is complex. Clinicians work in chaotic environments with sensory overload. Patients have their illnesses on their minds and don’t want to deal with complex software or convoluted terms. Let’s create a product that exudes simplicity and calmness.
Think about how Steve Jobs would look at our product and how he instilled a striving for simplicity in every product that Apple produces.
Build in small slices, with the end in mind
Referring to the Build-Measure-Learn loop above, building a car would take too much time before we can have our first learnings. We need to build skateboards and turn them step by step into cars.
BUT. We can only build a good car from a skateboard if we understand the core elements of the car at the outset and make sure these core elements are already in the skateboard. What is our end goal? What do we want our users to be able to do when we are implemented & used “at scale”? Think the end game through first, then decide which first step is minimally needed to start in the right direction.
Read more about beginning with the end in mind. Coincidentally (or not), this is the second time we’re following Steve Jobs. He said “begin with the customer experience and work backwards towards the technology”.
Create a common language
Building and implementing care flows is a job that is by definition done by a multidisciplinary team. The building and subsequently optimizing of care flows is an iterative process between builders and clinicians so they need to have a common language where they understand each other.
This means consistency in visual components and interactions across our platform. It means a consistent visual style. It means a representation that might not be exactly the same but is based on the same principles.
Be domain-specific
There are plenty of business process modeling (BPM) and other workflow tools out there. And yet, these tools are not widely used in healthcare. High level, there is no technical or functional limitation to these tools that prevent them from being adopted at a large scale. The limitation is in the lack of domain specificity.
The choices in our product should reflect the healthcare domain and the daily reality of our users. Instead of generic elements, go one or more deeper so the user can work with domain-specific elements instead of generic ones.
An example is offering a library of predefined steps that is tailored to the classification of the care flow. If Stef is building an orthopaedics care flow, he sees different “suggested” steps in the library than if he is building an oncology care flow.
Offer more than one way to get things done
Sometimes there’s no need for a decision on behalf of our users, or a decision would be counterproductive. People’s brains work differently, so we need to accommodate for this. In our product, this means that it’s ok and often even advised to have more than one way of doing something or visualizing something.
Creating transitions between steps is a good example of this. Stef can create transitions by connecting steps with lines, or from the details pane defining the destination in the transitions tab. Another is offering multiple views on the same thing.