We need to have a talk about (design) philosophy
As you’ve probably noticed from the last few blog posts, I’ve been thinking a lot lately about how biotech teams discover, evaluate and select software. And one of the big problems that I keep coming back to is how to succinctly and clearly communicate the differences between options that from a surface perspective look very similar. I noted a few weeks ago that some of this is because their marketing describes the outcome but not the tool. But there are also software products out there that implement very similar functionality while providing a very different experience once you start using them. So what’s the best way to try to capture those differences?
As an example, take ELNs. Sure, different ELNs will have different built-in peripheral components like inventory and sample registries and asset design. But if you look at each component individually, they all do more or less the same thing. And yet, different ELNs provide very different experiences, and ELN users often form strong opinions about what they like and don’t like.
If you don’t believe me, just look at how many biotechs use two or more different ELNs for different subsets of these components, even when one of them has all the components they need. I don’t have hard numbers, but it includes most startups that I’ve talked to. These teams are willing to deal with the headache of managing and integrating these systems because they prefer one over the other for specific components. (And this is despite claiming to want a single solution for everything.)
If you ask any of these teams why they picked each ELN, they may be able to tell you about specific features that make one better than the other. (Or they may roll their eyes and tell you someone else made the decision.) But most often, when they do have an answer, it ends up being mostly vibes.
Today, we’re starting to see the same kind of thing with emerging categories like bioinformatics platforms and automation software, with more surely on the way. So the question is what to do with vibes? Or rather, can we turn vibes into something that can help other teams decide what software will be best for their needs?
I think these vibes are the result of an unstated, and often unrecognized design philosophy that determines how a piece of software’s designers make design decisions. What kinds of activities do they make easier or harder? How do they expect users to think about their work? What kinds of user preferences are baked in? Each answer cascades into dozens of technical decisions about individual features. The underlying philosophy is what turns those dozens of independent decisions into a consistent experience.
Sometimes, the team that builds a piece of software can tell you their design philosophy. More often, it’s almost subconscious. But even when it’s conscious, it may be too nebulous to put into words. So these teams end up talking about what they built but not why.
But here’s the irony: While the “why” is often extremely hard to put into words, those words are usually much easier to understand. If you can tell a user who you’ve built the software for, you don’t need to tell them the dozens features that support that kind of user - They know if they’re that user or not. If you tell them how you decided what to make easy or hard, they can decide if those are the kinds of things they care about.
In other words, talking about design philosophy falls squarely into the category of things that are really hard to do but probably worth it. I don’t know how we can get to a point where it’s a normal part of how we think about and discuss software. But I’m determined to try.
Thanks for reading this week’s Scaling Biotech! I really appreciate your continued support, and I read every comment and reply.
As a reminder, I offer several services to help connect biotech teams with tools, practices and expertise to make their organizations more data driven.
For Biotech Startups: Sign up for a free consultation call to clarify a problem you're facing and identify the best options to evaluate.
For Software Startups: Add your application to the upcoming launch of the Biotech Reference Stack so your target users can find you.
For IT/Informatics Consultants: Learn how Merelogic can help you write white papers and case studies to define and demonstrate your specialized expertise.