Testing Mockups Before Coding — Lessons Learned from Past Startups Pt. 4
This is the fourth post I’ve written about some of the mistakes I’ve made with past startups. You can find the other three here:
- Alignment with Idea — Lessons Learned from Past Startups
- Alignment with Co-Founders — Lessons Learned From Past Startups Pt. 2
- Real Customer Development — Lessons Learned from Past Startups Pt. 3
This week we continue the theme of customer development mistakes I’ve made in the past. Similar to last week’s post, this one is about building the application too early, and how you can test your concept with wireframes and mockups before coding it.
Lack of testing mockups for Dokkit and ribl
We didn’t do any customer development for Dokkit and built an alpha version of the app too early.
After some debate about what the app might look like, my co-founders cranked out the V1 of the app in a couple of months.
A smarter path would have been to create mockups of the app and test them with our target audience.
You can create clickable mockups using tools like InVision, Balsamiq, or Mockflow (which I use) that simulate how the app might work and behave. It won’t look like the polished app you envision, but it can reflect the core features and functionality that the first version of your app might have. And you can create pretty detailed mockups in a few hours or days, not months.
Same with ribl. Instead of spending a couple of months to build the first version of the app, we could have created mobile mockups with InVision, Fluid UI, or the many other mobile mockup tools on the market.
And we could have tested these mockups on both Android and iPhone before spending all the time building for both platforms (another big mistake that I’ll probably blog about in a future post).
Because you can edit mockups easily, you can rapidly incorporate your testers’ feedback into the next version of your mockups and test them again. This rapid iteration cycle will allow you to continuously improve the “product” to the point where you’ll feel pretty comfortable that you’re building something people want.
Testing mockups with WinOptix
After I believed that the concept of WinOptix was validated via over 40 customer development interviews, I started working on the mockups.
It took me a decent amount of time putting these mockups together because I just didn’t have a strong vision of what the app might look like. I got some great input from Dave and Carolina, the developer and UX designer whom I’m working with, and incorporated their feedback into the designs.
After we were done with creating the mockups, I had a bad feeling that the tests were going to go horribly and that the mockups were completely wrong.
There was only one way to find out.
I reached back out to the people whom I interviewed and up until today, I’ve shown seven of them the mockups.
We weren’t as wrong as I thought we’d be, which was pleasantly surprising. I received some excellent feedback about changes that need to be made, features that should be added and subtracted, and what parts of the mockups really stood out.
It would have taken a few months to build a first version of the app that I mocked up in a couple of weeks. So we saved a ton of time, and I saved a bunch of my development budget.
My goal is to show the mockups to at least 15 people.
The ideal situation is that one of the test subjects becomes so impressed with the value that WinOptix might bring to their organization that they’ll pre-pay us to build the app. If that doesn’t happen, hopefully a couple of the respondents will agree to trial the app when our V1 goes live.
Regardless, we’ll review all of the feedback and determine what changes need to be made and how to proceed from there.
Conclusion
Testing mockups is a continuation of the early-stage customer development process and is a MUCH cheaper and faster way to obtain feedback from your target customer.
Your mockups might be completely wrong, or they may be on point. Either way, you’ll have a much better idea of what your next steps are without spending tens of thousands of dollars and/or months of your time coding the first version of your application.
We’ll see what happens as things progress with WinOptix, but testing mockups has been really beneficial so far.
I learned this lesson the hard way and I hope you won’t have to!
Here are some other resources about how to use mockups before building your app:
- Why You Should User Test Your Prototype Before Writing Any Code
- How to Run a Cheap, Fast, & Incredibly Useful User Test
- What are the best practices for testing usability of low fidelity mock-ups/wireframes?
What are your thoughts about testing mockups before coding your app? Have you had success doing this? I’d love to hear your thoughts in the comments.
