A post for those who want to see what an iterative, MVP-driven development of a feature looks like.
@lukew: Start with the simplest version you can. It’s much easier to add complexity than to remove it.
Once upon time, there was a webshop portal with hundreds of partner webshops displayed on the front page. Potential users wanted to find out if their favorite webshops or a particular type of goods were available, existing users wanted to find a shop quickly. Therefore it was decided to implement search. But how to do that?
Alternative 1: The waterfall search
We have immediatelly switched on our engineering brains and started looking at Solr/Lucene and the APIs of the webshops to be able to import their goods catalogues so that our users could find everything from one place. Luckily enough, we havent went far along this path. It would certainly take us weeks while the users would still have been stuck with the same unusable, unsearchable grid of webshops with only few broad categories to help them.
Alternative 2: Minimal viable feature growing iteratively
After the original diversion, I have focused on getting value to the users ASAP. Thus the development was as follows:
- Purely client-side search (or rather filtering) in webshop names, a case-insensitive matching of a substring
- Addition of a library that can do fuzzy matching so that even misspelled names are found
- Addition of keyword search – for each webshop we had tens of keywords such as “shoes” or “sport” so I transferred those to the browser as well and started to search them too. (The display of the results has evolved accordingly. I have also introduced lazy loading of these data not to impact initial load time.)
- I’ve moved the search to the server-side to save clients from having to fetch so much data and thus increase load size, especially on mobile devices. This also opened possibilities for searching other sources later on. That is where we stopped for the time being. (Thanks to using ClojureScript at frontend and Clojure at backend, this was mostly copy & paste.)
The good thing was that every few days we could have delivered increased value to the users. And I was also able to test the search on a frined (thank you, Fredrik!) early in the process and improve the UI considerably. (Weak search with good UI/UX may well beat great search with terrible one, it turns out.)
What could have been improved
It wasn’t perfect though:
- We actually did not deploy the individual iterations to the users for other reasons (but we could!)
- We had no monitoring in place and thus couldn’t know whether users used it (and thus that it was worthwile to develop it further) and how they used it or failed to use it.
- I’d have loved to see the impact on our conversion rates and active user base.
I love iterative development, doing the minimal thing possible to push value to users and get real feedback on it ASAP. In this case it turned out that a far simpler solution than originally envisioned, developed in few days, was sufficient. Win win.
You might enjoy also other posts on effective development.