Designing in Code Can Help Get Your Innovation in Market, Faster. Here’s How We Did It.

Because selling a big idea requires more than Keynote mockups.

Years ago, my team was charged with building a web app for a home goods company that had a very complex search and filtering mechanism. After countless internal discussions between our UX, design and engineering teams, we all agreed on a pretty radical concept. So, we perfected our design mockups in Keynote and marched into the client meeting with our heads held high. Ten minutes into the presentation, we could tell something was off. Our client just couldn’t grasp our big idea from our static mockups. They couldn’t visualize it. They didn’t see our vision, and left the meeting unhappy.

So, we went back to the drawing board. We knew our big idea was exactly what the client wanted; we just needed a better way to show them.

Then, a light bulb went off. What if we brought the mockups to life? What if we applied some quick and dirty code so the client can actually interact with them?

One developer and a day later, we had our interactive mockups. But along the way, something novel happened: We discovered flaws in our own work. Being able to actually touch and play with the concepts exposed some weaknesses in our designs that were not apparent to anyone on our team. So, we cleaned these up, redid the mockups, and re-presented to the client. It clicked. They understood what we were trying to do and signed off on the work, right then and there.

Years ago, our approach was a novel concept. Today, it’s just the way we do things here at Normative. We call it “Design in Code.”

At its core, it is a methodology that allows us to get to working code much faster than traditional agile or waterfall methods. Once you have software that works in the real world, it becomes much easier to understand and avoid the risks that keep your teams up at night and could sabotage your success. You get a clearer understanding of all the possibilities, and build the confidence to go in the right direction.

Earlier this year, we applied our “Design in Code” methodology to help an IoT healthcare startup, Inspiren, overcome a huge roadblock to get their product in market, faster. Here’s how we helped get them from a back-of-the-napkin sketch to launching in a major hospital in just 18 months.

Selling Our Vision

Early in their product development, Inspiren needed to prove to their investors and potential customers that their product “iN” could provide real value. They needed something magical to get them on board.

So we asked ourselves: What is the core job of this product? What do we need to show them to help them believe?

To us, it was simple: Medical errors are one of the biggest causes of death in U.S. hospitals. The iN system empowers hospital staff to eradicate one of the most common reasons for many of these deaths: patient neglect.

In less than 8 weeks, we built a basic, working prototype of both the hardware and the software to showcase how the iN system can do just that. Our prototype was in crude form from a development standpoint, but it was the perfect talisman to communicate the story of iN in a tangible and accessible way. It was exactly what the stakeholders and customer prospect needed to “get it” and green light the product forward to the next stage of development.

What are your riskiest assumptions?

Any product development effort always involves a certain amount of risk. To eliminate risk early on, good teams work to identify the riskiest parts upfront and tackle those first. When the VCR was being developed, for example, the riskiest assumption was that people would actually want to watch movies at home. As radical as their assumptions were at the time, they proved correct.

We tend to adhere to the “fail early, fail often” approach to managing risk. While working on iN, we identified the most risk-inherent pieces of the project and focused on removing those risks first. For example, if a call bell is triggered by a patient, how quickly can the application detect this and notify the responsible parties? Our initial coded prototype had a small delay before sending out proper notifications. Working in code allowed us to play out a few different scenarios to see the best, and safest, path forward. We were able to tweak our algorithms to detect call bells and notify nurses nearby instantaneously.

We quickly went from asking ourselves “will this work?” to asking ourselves: “Now that that risk is eliminated and our assumptions have been validated, what other value can we add to the product?”

Why we always design in code.

When you are working against your riskiest assumptions — the real world comes at you, fast. Suddenly, you’re no longer dealing with simple design issues on paper. You’re up against technical issues, hardware and material restraints, industry regulations, and psychological barriers of your end users.

Our strategy especially made sense for a company like Inspiren. Their core focus is on protecting hospital patients and empowering hospital staff to create a more consistent, reliable, accountable environment for them. The stakes are extremely high. Because we started designing in code from the start, we could more easily spot all the bad design decisions and technical issues early on; issues that could very well have been life-threatening issues, had they shown up too late (or not at all).

iN went on to be recognized by Fast Company in their 2018 Design by Innovation Awards and is currently being implemented and deployed by two of the largest healthcare systems in the United States — including a top 20 hospital ranked by US News and World Report — with implementation discussions occurring with a half dozen other top hospitals across the US including the Veterans Health Administration.

Wrapping up

A deck can only get your product or idea so far. A picture is worth a thousand words, but a prototype is worth a thousand pictures. You need to get to working software quickly, knowing that you are making the right decisions along the way. You need your stakeholders, both internally and externally, on board early with confidence that your product development is on track. “Design in Code” has proven itself time and again as a viable and valuable approach to getting our, and our partners, best ideas to market — fast.