Return to site

Solutions to the Biggest Microfluidics Pitfalls

Part 1: Technical Challenges and Usability Problems

Despite 25 years of commercialization, nearly all product development efforts involving microfluidics still fail. I know what you’re thinking: the same is true in every other field, and you’re right. But the time has come for both startups and established companies to learn from the past mistakes (and the sprinkling of successes) made by others.

We’ve seen the same mistakes over and over, so we decided to collect a list of the biggest pitfalls made in microfluidic product development and investment. More importantly, we’re also providing recipes for avoiding these mistakes.

Whether you’re a product developer or an investor evaluating a potential product, please read on. For each pitfall, look to our suggested solutions for microfluidics developers and for microfluidics investors.

Part 1: Technical Challenges and Usability Problems

In the first installment of this series, we’re looking at factors that mean the difference between a product working in the laboratory and working in the field.

We’ve all seen those great images on the covers of high-impact journals. Microfluidics can sizzle, but often the substance is lacking, at least when it comes to commercialization. The following pitfalls relate to whether a piece of technology is really ready to go to market—whether it works properly with real-world samples, and whether your end users can make the device work properly.

Pitfall: The device function relies on properties of physiological fluids

Many microfluidic chips use blood, urine, saliva, or other complex samples. Such fluids can have an immense range of properties, including viscosity, surface tension, density, and optical clarity. Often, specific microfluidic features have been designed and tested using model solutions or samples from healthy donors, and consequently work only when the real-world sample falls into that narrow range.

A common example is capillary action, where a fluid meniscus is expected to either advance or stop based on surface tension. The surface tension of blood or urine varies tremendously, even within a single patient. If the device hasn’t been designed with a mind toward this entire range, it will not be viable as a product.


FOR DEVELOPERS: Avoid designs in which a physiological parameter must fall between two values, unless those values are very far apart. Instead, try to use just one value as a limit—for example, a device that works when surface tension or viscosity exceeds a lower-limit design factor, or when density exceeds an upper-limit factor.

FOR INVESTORS: Ask what percentage of the population the device covers. The answer will tell you whether the developers have considered the real-world range of conditions. Be skeptical if the answer is, “Oh, this should work for everybody,” without further explanation!


Pitfall: The device incorporates too many elements to perform reliably

A functional design that meets design specification 98% of the time sounds pretty good, right?


Almost without exception, these devices will not perform reliably. If each element inside a device (channels, valves, reservoirs, mixers, pumps, capillary stops, vents, junctions, bifurcations, etc) has a 98% chance of meeting geometric and functional specifications, then a device with just 10 elements has an 18% failure rate. A device with 20 such elements has a 33% failure rate. By 35 elements, the device fails more than half the time. If the individual element success rate is 99%, even with just 5 elements (a remarkably simple device), the failure rate is still 4.9%, a number that is unacceptably high for most applications.


FOR DEVELOPERS: Simplify! If a feature isn’t absolutely necessary to give your device the required function, then eliminate it from your design. Those features that are included should be as simple and robust as possible. Remember the difference between 98%, 99%, and 99.9% success rates and how they translate to overall reliability.

FOR INVESTORS: Ask the developers about the failure testing they’ve performed. For failures they’ve identified, ask how and when they plan to address these failures.


Pitfall: The testing to date has been done by only “special users”

From a usability standpoint, no credence should be given to testing done only by the developer. Such users are “special” in the sense that they are practiced and have great familiarity with the device. These users are wholly unrepresentative and cannot be considered reliable subjects in determining the usability, compliance, or clarity of instructions for use among a realistic user population.

One common usability failure point is requiring the user to provide a sample by lancet or swab and apply it to the device. Success rates at such techniques vary immensely between practiced users and first-time users.

Similar issues plague devices in which a fluid must be pipetted, or otherwise introduced in a controlled way, onto a plastic disposable chip. Again, developers who’ve had hundreds of practice runs are always far better than the average end user.


FOR DEVELOPERS: It’s never too early to test a design or the instructions for use. Whether it’s a family member, friend, or another person who works in the same building, feedback is always valuable. A few outside users will give a more realistic assessment than anyone inside your company.

FOR INVESTORS: Try the device out yourself, or at least get a live demo. No amount of data will convince you (positively or negatively) as much as seeing the device in action for yourself.


Pitfall: The system has complex external components or setup/calibration process

Remember those flashy journal cover images? Well that’s just the device itself. Behind every device is a piece of hardware that’s an essential part of the system. Examples include fluid pumping and valving, optical interrogation, and the software required to drive these functions.

Ideally, everything external to the plastic consumable is extremely simple and reliable. Too often, though, and especially early in product development, the hardware is a hodgepodge of tubing, wires, and glue running on a clunky volume of code. Getting reliable data from these systems typically requires careful setup, delicate calibration, and manual interpretation.


FOR DEVELOPERS: Always draw a clear box around your innovations. Delineate routine product development (for example, replacing a basic breadboard circuit with a low-cost printed circuit board) from intense, potentially messy research and development. Always keep in mind the full scope of device commercialization.

FOR INVESTORS: Distinguish what aspects of product development will simply require time and money from those that require an actual technical breakthrough, however small. If the hardware or software merely needs some standard engineering work to reach product status, that’s great. If it needs one or more breakthroughs to become a reliable, usable product, always remember that no amount of time or money guarantees a breakthrough.

The common element to all of these pitfalls is insufficient thought and testing under real-world conditions. The bottom line for avoiding these classic mistakes is to ensure you’ve captured the full scope of your project.

For product developers, that means fully understanding the operating principles of your technology and not overlooking major factors that will impact your product in the field.

For investors, it means pressure testing your targets to confirm they’ve truly explored the reach and limits of their technology, and that there are no bad assumptions about bringing the product to bear in the real world.

Stay tuned for the rest of our series on pitfalls and solutions in microfluidics. Future installments will discuss materials and manufacturability as well as validation of markets and applications.

All Posts

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!