I?ll be the first to admit it: Our environmental chain of custody software, ezCoC, is not awesome. Not yet anyway. What I have learned over the last 2 years in developing this product is that making software that doesn?t suck is really, really hard. Sure, it might be easy to come up with an idea, such as the idea of replacing paper forms with electronic forms on an iPhone. But actually doing it, in a way that doesn?t suck, is really difficult. And if the software is intended to change user habits and behaviors (which is the case with ezCoC), then it?s an uphill battle that is even harder to conquer, especially in the environmental consulting industry, where inertia has set in pretty deep with current practices. Getting users to even consider trying an alternative approach to something as basic as filling out a chain of custody form electronically on a smartphone has so far proven to be a massive mental challenge for many of us.
It?s Not Easy To Do
Building software like ezCoC takes a hefty amount of time, money, internal evangelists, expensive software components and tools, servers and bandwidth, and a team of smart people, including developers, network admins, and testers. Then you need to get the word out. That requires a content management system like WordPress or Hubspot, people willing to produce content for that website, including help documentation and a tech support case system with FAQs in it, consistent blogging, search engine optimization on your content, metrics and keyword tracking, social media activity, and a whole host of other marketing-related tasks like attending trade shows, phone calls, and such. As you can see, building software is not just about the code. In fact, the code that makes your software product work is just one of many moving parts.
In our case, many of our environmental folks weren?t used to doing these things. Instead, they were used to doing typical environmental consulting projects: bid on a job, write the work plans, schedule and conduct the fieldwork, analyze the resulting data, and put together a final report. They were not bloggers or software testers. It was all new to them. And when something is new and different, it can cause uncertainty and tension in the ranks. Some will step up, some won?t.
For me, building ezCoC has been among the biggest challenges I?ve ever done in my 21 years of running an environmental consulting practice. It?s been difficult migrating from traditional consulting to building software for our industry. Getting all the moving parts together to produce a software product that actually works has not been a walk in the park. And even more difficult has been the job of evangelizing the product vision, one that is actually pretty basic: replacing paper CoCs with electronic ones using web and smartphone technology. Even 2 years into this, our software is still not up to snuff, and the doubters and critics are everywhere, which is hard to believe in 2012, when more than half of the US population carries a smartphone in their pockets.
So how do we do it? How do we build a software product that, in the end, doesn?t suck? For our team, it?s by doing the following:
keeping it small and simple
building relationships with partners
listening to our users
I started this whole thing by first coming up with the idea intended to solve the latency, transcription, and communication problems between field techs and labs that are inherent with the use of paper CoCs. This was followed by hashing and rehashing the idea in my head many many times, and then finally putting that idea down on paper. But instead of writing a bunch of text and procedures, or drawing a complicated Visio diagram, I used Balsamiq Mockups software to get the ideas out of my head and into a medium that others could really understand and interpret.
If you are not using a wireframing tool to design your user interface (UI), you are wasting a lot of valuable time, and your product will suffer. Balsamiq Mockups is inexpensive, a cinch to use, and can provide visuals that everyone will understand. Not only that, but by doing this exercise, by mocking up your concept that is locked up inside of your head, you will be able to better understand and improve your original ideas. Just by using Mockups, your ideas will easily improve by an order of magnitude, as your creative juices will begin to flow and some of your original ideas may morph into other even better ideas.
Keep It Small and Simple
No doubt that Apple has shown the world that less is more. A phone with only five buttons. Simple, intuitive controls. No thick user guides or operation manuals. One way to shut down a computer instead of four (in Windows: Hibernate, Sleep, Restart, and Shut Down). My opinion is that all software should follow this same ?less is more? principle. Keep it simple, with fewer choices and options.
As your software product matures and more users use it, you will inevitably get many requests to add this or that, to change the flow to accommodate a user or a specific use case, and so forth. But you have to be willing to say ?no? more than you are willing to say ?yes?. It will mean that you will lose some users, but in the long run, a simple and intuitive UI is more important than catering to everyone?s unique workflows, needs, and desires. The last thing you want is for your software to become unwieldy and complex. Less is more. Keep it simple.
Build Relationships with Partners
Sometimes you can?t go it alone. Sometimes you need partners, which can act as catalysts to get your product noticed and moving in the right direction. In our case, we are working with Promium, whose Element LIMS software is currently installed inside of 250 of the 800 commercial labs in the US. Tight integration of our electronic chain of custody system with the LIMS leader in the environmental lab industry should offer us that needed boost. More about this in a future blog post.
When you can, reach out to others in the same industry that can complement your software. They are out there. You just need to look, reach out, and keep reaching out until you find the right ones.
Listen To Your Users
One of the take-away messages that resonated with me from attending this year?s Business of Software conference this past week is that you really have to listen to your customers. Really listen and try to understand what they are trying to tell you. And you should focus on the negative feedback without getting all defensive about it. Don?t ask for positive feedback. That kind of feedback doesn?t help improve your product one bit. Ask for negative feedback. Ask them what they don?t like about your product, and then do something about it. If you are getting the same negative feedback or suggestions from a bunch of your users, then make those requested changes. However, if it?s just one or a few folks suggesting something, keep that suggestion in the back of your mind, and change your software to address those issues only if you continue to receive similar feedback from more users.
I?ll confess that we haven?t done enough of this. Two years ago, I had an idea for an electronic chain of custody system using smartphones, and I got it built to version 1.0. It does things the way I perceive they should be done. But we have received enough feedback that suggests that selecting an analytical method within ezCoC is still complicated. So we are now working on improving that area of the UI in an effort to make it drop dead simple.
On the other hand, we?ve also received feedback about use cases that are very specific and unique. Those sorts of suggestions will have to wait and may never see light in our product. Why not? Adding options all over the place, so that a single tool can handle every single use case under the sun, will make the system even more complicated, and that?s not where we are going to go. So while you need to listen to your users, its still a balancing act. Listen to your users, but don?t over-complicate your product. In the end, less trumps more. Simple trumps complex.
Build. Test. Learn.
Build. Test. Learn.
I remember in 1980 when I was a young kid at Culver Military Academy, one of the cadets in my barracks was graduating, and his parents were giving him a car as his graduation present. It was a Honda Accord CVCC. He was devastated. He thought he was getting a Camaro or Corvette. No, he was getting a crappy 72 horsepower ?car?, which was basically a glorified motorcycle with doors. Flash forward to 2012, and the modern Honda Accord is pretty impressive. How did they do this? Honda continually iterated and improved the Accord, until it far surpassed Detroit?s offerings. The Big Three didn?t even see it coming…or they did, but thought that it was too crappy of a ?car? to even worry about.
While our software product may not win any awards yet, it continually improves, just like the Honda has over the years. And one day in the not too distant future, we will land at a sweet spot, where the functionalities and benefits offered by ezCoC far outweigh the negative concerns or doubts some people have about it. That time is coming. It?s inevitable. And the reason is because we continually iterate and improve it.
Making software that doesn?t suck is truly hard to do. Our first version of ezCoC is not a standout yet. It might actually suck at some functionalities. But it?s getting better all the time. We are learning and applying the principles mentioned in this article. We are not there yet, but we are getting there, one line of code at a time. And I still believe that one day, perhaps even as soon as 2013, our little software product might just become a gamechanger in this industry.