Loveablity

[richardbirkin]

We often talk about SLC - Simple Lovable Complete - as an alternative to MVP - Minimum Viable Product.

On the phone this week, Greg mentioned that he's been using the concept of SLC not just strategically, but atomically at every level of his work on another project.

We chatted about making something Loveable. Our prototype is not Loveable. We Love it because it works. The user will just see a table get loaded instantly when someone uploads a CSV file. They might Love that their lives are made easier by the software, but they should Love using it.

We talked about the upload to display process from the user's perspective. Even if the software can do this instantly, maybe it shouldn't. Maybe it could do something...nicer. For example, crank up the volume to 11. I can't remember what service does this, but I remember recently seeing a loading bar telling me that it was doing something with Spimes. The BBC iPlayer volume goes up to 11. These sorts of things can make something feel loveable, a joy to use.

So there's a potential move away from the Better Motherfucking Website mode of thinking where everything is as basic and bare bones as possible. And there's a difference there between simple and bare. Swiss design is simple and loveable. A bare canvas is not loveable.

....anyway...just some thoughts that have been rattling around in my head in the June heat.

[g105b]

Off the back of this, the way I've been adding SLC to another project has proven to be really successful - not just treating SLC as a concept, but applying it as a development methodology.

For each deployment of a sprint, the S, the L, and the C should all be defined. We should make it so we can't deploy a new sprint until the following questions are asked - each time:

1. What does this deployment do to add simplicity? For each new feature of a piece of software, it's really easy to increase complexity, so forcing ourselves to increase simplicity for each deployment is a must.
2. What about this deployment is loveable? Like you said, it shouldn't just be loveable because we love it - what would make a user love it?
3. What about this deployment is complete? This one's easy to get wrong, because deploying a sprint feels like completing something, but what does the newly shipped functionality actually complete? This might be the last of a collection of smaller features, or the functionality might complete the thread of a user journey... but it shouldn't be seen as complete just because the code has been completed.

I've got into the habit of adding the three headings into the pull request, as a way of framing the contents of the sprint. It's also a good tool for looking back at previous deployments, because the three points give the deployment a memorable definition of what functionality is contained.