Guest Article: Achieving product simplicity in healthcare offerings is hard but possible

_I’m a geek and proud of it — I love building software, launching new products, and am a fan of others that do it well. Recently I ran across the Berlin-based team from kenHub, a site focused on teaching anatomy online and helping medical students prepare for tests. I reached out to the team to ask them how they were differentiating themselves from the many other solutions available they said their goal was to simplify the process of learning using new didactic concepts to focus on memorizing and gamification elements to make it fun and engaging. Simplifying designs to make complex tasks easier to perform is something that almost everyone in healthcare should be doing so I reached out to Johannes Köhler from kenHub to see how they did what they did and what advice they have for the rest of us. Here’s what _Johannes and his team said:

Albert Einstein was quoted saying that “Everything should be made as simple as possible, but not simpler.”

How do you achieve simplicity in your healthcare product but still retain its usefulness? What can you do to simplify your product delivery process? Does simplicity really matter?

Our goal at kenHub is to simplify the learning experience for medical students. Each student is confronted with an overload of information before becoming a medical doctor. A substantial part of their study is dedicated to the human anatomy. While understanding functionality and relations between the structures is one aspect of it, being able to name and memorize up to 8000 anatomy structures is another. kenHub aims to improve the memorization process of these structures with its online anatomy trainer. Students using our product get the anatomy vocabulary deeply ingrained, to later communicate fluently in their jobs as MDs.

Simplicity is therefore not just a ‘nice-to-have’ feature, but a core requirement. Simplicity influences all areas of our company. From the code we write, through the way we deploy, and all through the end-product used by our students.

Less is more

Many features are interesting to implement, technologically advanced, or present a mental challenge for the developers, but aren’t often as useful to the customer. Before we implement a feature we think long and hard: Is it really necessary? Will it definitely help our students? Or could it add complexity or distract them from learning? One of the most important tools to achieve simplicity is minimalism. Keeping things clean, clear and to the bare minimum.

But when designing a learning platform that covers thousands of pieces of information, how can you make sure all information is presented without information-overload? The key here is using the time element, to ‘stretch’ information. The user never gets overwhelmed or distracted by too much information at the same time. It is displayed gradually. This applies even more when it comes to mobile devices where screen “real-estate” is far more limited.

The right level of detail

Many people ask us why we don’t use 3D models. We think they are great for understanding the context but also offer an overload of information which, as some research suggests, could actually make memorizing harder for you. In the era of ‘big data’, statistical analysis, and parallel processing, it’s easy to throw as much data at your problem, and hope this will help you solve it. The solution can be in clear sight. Distilling the information you need, and at the exact level of detail is key to understanding. Asking the right questions helps you find the right answers. Computers can crunch numbers, but only our intuition can guide them to do the right work to figure things out.

And every MD knows that in the end it is greatly about intuition when it comes to making a diagnosis. The body sends out an overload of signals. Alone, these signals do not allow one to formulate a decision.

Done is better than perfect

The lean-startup methodology, and the facebook-attributed “done is better than perfect” theme can go a long way towards keeping things simple and effective. When we started building our learning platform for healthcare students last year, we wanted to get a Minimum Viable Product (MVP) out the door as soon as possible. Students could start using the first lecture and give us valuable feedback very early. This allows us to continue improving it, knowing whether or not we are on the right track. We interviewed students at universities and others we contacted online, and gathered feedback. We kept asking people for ideas and comments on our website, via email and whenever we talked to them personally. The same goes for launching the paid-for product. Only 5 months after our first version, people could pay for additional content. Even though our product was far from complete or comprehensive, we asked people to pay for it. Why?

Firstly, we were able to find out if students are really willing to pay for our product. People will generally be positive when you talk to them, but being willing to pay for something means a completely different thing. Secondly, paying customers are the best source of feedback. They care for what they paid for and want to get the most out of it. Not only did it give us better user feedback, but it also provided a huge motivation, seeing that people find real value that they would actually pay for our product. Even at an early stage, and when it only covered a small part of the human anatomy.

Using fast product iterations, and constantly testing your approach as you go along provides a much simpler method for making progress. Don’t expect a huge outcome, only gradual improvement. Adopting a “done is better than perfect” mentality, means you accept imperfections, and value change over stagnation. If you view your product as a series of small changes, and focus on the next step, you can’t make a huge mistake. If you do make a (small) mistake, It only takes another (small) change to fix it.

We know that this approach can’t be applied fully to every healthcare product, but whenever you have the chance, go out, gather feedback and pivot, if necessary. That way, you take smaller risks instead of a large one that can make your project fail.

Review, Test, Deploy. Continuously.

Our goal at kenHub is to deploy as soon as a feature is done. We don’t wait for a specific day, and create a big deployment with lots of new changes. Each deployment is faster, smaller and carries less risk on its own. This is possible when you have a framework (both technically and methodologically) to ensure your code is fully tested.

Using Test Driven Development (TDD) means we are writing tests before we write our code. This not only makes sure our code is tested, but also guides our development to think about the use-case before we implement it.

We also review every piece of code before it goes into production. If you are a developer and don’t let your code being reviewed you are probably doing something wrong! We are all human beings who are not perfect and we do make mistakes. Reviewing gives you the opportunity to learn from others and for others to learn from you. Code reviews will quickly tell you where you make mistakes, where your code is not simple enough or where a comment for better understanding is just missing. It also increases the overall familiarity of the system for all developers. The one writing the code, as well as the one reviewing it. If you only have one developer in your company you really should get another one. The GitHub pull request feature makes it easy to make the review process a part of the standard development flow.

Continuous Integration allows us to have clear visibility of our code base at any stage. From the stable branch in production, through the individual features being developed. A feature can only get deployed into production when all tests pass, and after it was reviewed and approved by at least one more team member.

Some features might need to be launched at a certain point of time, or we might need to soft-launch it to a subset of users first, to “test the water”. Feature flags allows us to decouple deployments from releasing our features. They allow you to switch features on or off, enable them to a subset of users, or to ramp-up over time. If a feature does not work as we’d expect it, or put the system under stress, we can simply turn it off. No deployment is necessary.

Those building blocks of our development, deployment and release processes provide both stability and agility. We can react fast, but this does not mean we do things haphazardly. Simplifying and streamlining these processes gives us the confidence to apply change as soon as it’s necessary.

Parting thoughts

Keeping things simple in healthcare offerings is far from easy. It requires careful planning, care and consideration. It forces you to focus your energy, identify the essence and throw away any distractions and overhead. But simplicity often pays off. Our focus on simplicity helped us and our customers immensely. We were able to identify early if we are still on the right track. We were able to release new features and adapt to change quickly. The end result is having an effective process that we enjoy working with, and ultimately, giving our customers a product they love using.