Harsh rules for fine design
Robert Virding (author of several programming languages) has a great talk about programming language design, and it occurred to me that some of his philosophy applies quite nicely to the design of software products, and even product-design in general.
Below are a few of Robert’s design heuristics (in no particular order).
- Focus: solve a specific problem/area
- Don’t be nice to users: users only want what they think they want
- Provide tools, not solutions: don’t over-do it
Let’s investigate each in turn.
Focus
If a product tries to be everything to everyone, then it means nothing to all. In marketing, this is a bedrock rule-of-thumb, and remarkably, it can be applied to product, language and other design realms, as well.
Pretend for a moment that a start-up creates an ‘app’ called ‘Wagons West.’ The ‘app’ captures photos on smartphones and then shares on social media those images in drab sepia ol’ timey colors. This ‘app’ has focus; even the name is complimentary to what it offers. Then, imagine, for whatever reason, the start-up bolts on a five-day weather feature. In theory, ‘Wagons West’ now has more value. But it’s a value that comes at the expense of the start-up’s core offering.
Diluting the goals of your brand, product or programming language by offering the world, is short-sighted. In the long run, it hurts you.
Don’t be nice to users
As Steve Jobs once said: ‘Users don’t know what they want.’ Typically, users don’t see the whole picture, and more times than not, their suggested feature is one they only think they want.
If founders are to ask for feedback (in interviews or otherwise) they should ask users to play devil’s advocate. Give them that licence. Ask them, ‘what three things do you deplore about the product?’ Or variations on that theme. By blankly asking users their opinions, users tend to give false negative feedback. Moreover, people are too kind; they don’t want to offend. So in the end, asking their opinion about what they like leads nowhere.
Something General Secretary Gorbachev said: ‘better to see something once than to hear about it a hundred times.’ So, put those analytics in place, sneak down to the factory floor in plebeian clothes, and stop asking users to shape your product.
Provide tools, not solutions
You may think tools and solutions are different sides of the same coin. And they are kissing cousins, for sure. But here is the distinction: in providing solutions, designers fill all the gaps for users. What results is a product that is convoluted, clumsy and one that simply promises too much.
A fork can be used to pick something up off our plate. But turned sideways, one can use the blunt edge to saw away at something more unforgiving. It would be silly to put a serrated edge on the fork, even though that’s what we end up doing when making software, don’t we?
Don’t over-engineer. Have confidence that given a straightforward tool, people will find creative ways of using it. We don’t have to make these discoveries for them. Let users express their solutions with your tool, and don’t be tempted to cater to all their specific needs.
Design in general
At the end of the day, whether it be a programming language, a tangible product, or what have you, our designs can rise to excellence if we can focus, stay true to a single mission, and avoid over-engineering. Obviously, it’s hard to push against feature-creep and feature requests; but we should try and get our way. Rest assured that good design requires this discipline.