When you're creating a new feature or adding functionality to your web app, you typically don't have time to dive into the minutia of every aspect of how the feature will look, behave, and function. Obviously you can indulge yourself into that level of detail, but it is typically the most time consuming aspect of a feature and it shouldn't be tackled until the minimum required functionality of the feature is complete.
If you get caught up in the sexy or fun part of the project, the user-facing portion, it's possible you'll use all of your allotted time for the project carrying out non-critical feature development and you won't be able to release anything as your feature still isn't functional. If you develop in such a way that you make the feature usable and functional first, you can spend all the remaining time layering on the subtleties of good UX. If things go wrong and you end up having very little time to layer on the aesthetics, at least you can release the feature and come back to the subtleties later. This strategy for building features is commonly known as Minimum Viable Product (MVP).
I am a very big proponent of developing with a MVP mindset. If I'm given a 3-day window to work on a project, I'll determine what the MVP and critical path for that project is within the confines of 3 days. With this mindset, my only enemy is scope creep. Scope creep is inevitable with every project and unless it's absolutely necessary, my natural reaction is typically 'great idea, but it should probably go in version 2 of this project'. This approach is a double-edged sword. Because I take this stance, very rarely are my projects not completed by the designated time; however, it's possible that the MVPs I develop are too bare-boned to be a feature that users will be delighted by. This is where we enter a gray area.
I can go the extra mile and try to delight the users, but then I will run the risk of spending too much time determining what I think the users will perceive as delightful, which is highly subjective and not always obvious. It leaves a certain level of uncertainty in determining the completion of the project that I'm not comfortable with.
The concept of building towards a delightful product, or Minimum Delightful Product (MDP), was coined by either James Reinhart or Oliver Lubin, I can't remember which. Respectively, they are the CEO and CCO of the company I work for - thredUP.com. MDP is a very forward-thinking strategy to product development, but I'm going to go against the grain and disagree with my bosses and their concept. Before I do so, I want to elaborate on the idea of MDP.
I believe MDP is the evolution of another strategy that bares the same acronym, Minimum Desirable Product. Minimum Desirable Product is the simplest experience necessary to prove out a high-value, satisfying product experience for users. That definition is a direct quote from Andrew Chen's aptly named blog post 'Minimum Desirable Product'. In this post Andrew Chen (@andrewchen) explains that MVP tends to center around the business perspective of a feature and what you really need to focus on is what feature your users desire.
What my co-founders argue in favor of building for delight over desire is that sometimes what users want (desire) is different from what will actually 'wow' them (delight). If users were able to add every feature they desired, you potentially could end up with a cluttered product. While there are many examples of this, my favorite is the homer-mobile. Homer Simpson once created his dream car with every bell and whistle he could possible want, but it ended up looking like this:
I could also demonstrate the other end of the spectrum by showing a product that succeeded in ignoring feature requests and still delighting their users - the Apple iPad. Users wanted Mac OSX on the iPad and countless other features, but Apple determined the core experience they wanted the iPad to emanate and built towards that while letting many features fall by the wayside. I think we can all agree that the iPad has been a smashing success and the simple experience and usability is a fundamental reason why. I'm not saying that building for what users desire leads to building cluttered apps, but there's definitely a gap between what users desire and what will delight them. Because of this I believe there is great merit to the Minimum Delightful Product way of thinking. So why am I hesitant to buy into it then?
The reason why I am hesitant is that 'delightful' is a very subjective term and assuming you know what the users will consider delightful is a bold statement. Outside of Apple and a few other companies, most struggle with always delivering a delightful experience and if you're not in your product's demographic (like myself), it becomes even harder to identify what will be delightful for users before the product is built. I'm not saying building a Minimum Delightful Product is wrong, I'm just saying it's difficult and you're bound to arrive at the wrong subjective assumptions every once in a while.
I don't believe in criticizing without offering a solution, but my spin on the strategy is kind of a cop-out as I believe the right approach is a balance of all three. Obviously the complexity of the project and resources available will always dictate your flexibility on strategy, but in the optimal environment I would prefer to build an MVP that is structurally sound on the back-end and then put a thin layer on top that will elevate the feature to what the users desire while showing glimpses of how version 2 of the feature would delight them. It's basically right in between building desirable and delightful product.
With this approach, you are less likely scrap work made on inaccurate assumptions. The only requisite to my approach is you have to schedule version 2 of the feature very soon after version 1 is complete. If you don't bake V2 into the schedule right after V1, I doubt you'll come back to V1 and ever make it a delightful feature for your users. Build V1 -> collect feedback -> adapt the feature -> release V2. It's eerily similar to the 'MVP -> release -> iterate' agile workflow, but somehow in my head it's different in all the right ways. I think I'll call it the Minimum Dan Product so I can have another MDP acronym to be confused with.
