SUMMARY
And The Secret To Building Products People Understand
If you’re like me and love seeing new apps and products, you probably poke around on Product Hunt ? every day.
Let’s say you find something that sounds interesting — like a product from a new startup that is (once again) trying to re-invent email marketing.
So you grab the link, head over to their beautiful looking landing page that was built just for this special Product Hunt launch, and sign up for a free account.
The onboarding flow is great. It’s clean, simple, and gets you right into the email editor.
You type up a quick email so you can send something to see how everything works.
But wait.
“Where’s the send a test button?”
“And how do you add contacts to a list?”
“They don’t have the concept of lists?”
“How do I actually pick who I send this to?”
And just like that, you’re gone. Back to browsing Product Hunt and on with your day.
Damn.
That scenario is one of the biggest mistakes that I see product teams make all the time.
I’ve hired hundreds of designers and engineers, and the same thing always happens: they want to invent something from scratch, instead of leveraging familiar patterns that customers already have muscle memory using.
The startup in the example above tried too hard to come up with their own solution and lost me as a result — vs. seeing how email marketing companies with millions of users like MailChimp have done it, and innovating on that pattern.
And the best startups have been innovating on existing patterns for years.
Take Slack for example…..
Or Sunrise….
Or Mailbox…
I’m not sure why we always keep trying to invent something from scratch, but it seems universally true.
Maybe it’s because the boundaries are softer.
Maybe it’s because a newer craft.
Maybe it’s something else.
Anyway, it’s one of the biggest issues I see with companies new and old.
If you asked a craftsman to build a chair, it would come out looking something like this:
But here’s what all of us working in software want to build:
So how should things work using this chair example?
I think there are two accepted ways to design a chair:
- Emulate what works today with common chairs (laws of the universe = legs, seat and back) and then innovate on top of that fundamental design to bring your unique view to the design.
- Ignore the common patterns and quickly prototype something from scratch and start to refine from there based on user feedback, usually from the client who commissioned the piece (Can I sit in this thing comfortably).
I think that we should emulate the chair maker when it comes to building software by designing software following either of these two paths:
- Emulate what works today and then innovate on top of those basic patterns. Look at what software a customer uses today and reuse as many patterns as possible and then innovate on top of these patterns.
- Ignore common patterns and quickly mock something up and begin to refine that mockup based on customer feedback before building and releasing that feature/app.
Leveraging existing patterns doesn’t just save teams from wasted time building products and features no one will use — it helps your users to not feel stupid.
As Steve Krug said: “Don’t Make Me Think.”
If you want to go deeper on this topic, we talked about it this week on Seeking Wisdom:
First published on Medium by David Cancel.
