A basic Lean Startup technique is doing the smallest thing possible to learn from customers. Applied to the product, this often translates to a visual mockup of some sort to stand in place of the actual product. Mockups are a great way to qualitatively test that you have a problem worth solving before committing yourself to build out the particular solution. I use mockups quite heavily both before and after launch, but not all mockups are created equal.
I only create mockups using the “technology framework” in which the product is delivered.
For me, that is HTML/CSS/Javascript and Ruby on Rails.
Here’s why:
The mockup needs to be realize-able
I have friends at design studios that have special teams in place to build early user mockups/demos in Flash. These demos are very much part of the sales process, and a lot of emphasis is placed on them. While they are quite effective at making the sale, they make the job of the implementation team quite difficult — with many of the more “flashy” elements being sometimes impossible to recreate in HTML/CSS. This leads to a disconnect between what is promised (and sold) to the client and what is eventually delivered.
Photoshop mockups, while not as “flashy,” can still be embellished with hard-to-recreate gradients, fonts, and shadow effects that can deviate enough from the actual user experience to make them hard to deliver too.
The mockup needs to look real
I don’t like going the other extreme, either relying on barebone wireframes or sketches. While they are faster to put together, they require the customer to take a leap of faith in the finished product, which I try and avoid. That said, given a choice, I will probably prefer to under-promise and over-deliver on the user experience than the other way around.
The mockup needs to be quick to iterate
By iteration, I am referring not to design iteration but the total time to deliver a finished, functional screen.
The mockup needs to minimize waste
Creating a mockup in anything other than the final technology in which the product is delivered creates waste. In the case of a flash/photoshop mockup, the only thing that survives is the design. Everything else has to be converted, usually to HTML/CSS.
Next, I’ll go a little deeper and talk about how I build these mockups:
From Sketch to Mockup: Controller-View-Model
There is well known Model-View-Controller (MVC) pattern for building web applications. I build and test my screens by going in reverse order.
Controller
The controller defines how the various pages of an application fit together to create a user flow. I always start here first.
You need to think in terms of flows, not screens.
- Jason Putorti
If this is a brand-new app, I need to build a skeleton app first. I define placeholders for all the views (pages) and wire them together for optimal navigation. This part is a snap in Ruby on Rails using controllers and routes.
If this is an existing app, I must decide where to inject the new screen and update the navigation flow accordingly. We implement a continuous deployment system where all commits are immediately pushed to production. To isolate partial changes like these, we use a “feature flipper system” to control who can see these changes. Once we are ready, we use this system to incrementally roll out a mockup (eventually the full feature) to additional users.
View
I will then pick the “most impactful” view(s) and start designing those. I might do a paper sketch first if it’s particularly complicated. Other times, I’ll jump straight into HTML/CSS. At this point, there is no underlying “model.” Everything on the screen is hard-coded HTML. But instead of using “dummy data” (lorem ipsum), I will come up with “real looking data” so the screens help tell a story about the feature in use. At this point, the mockup is ready for customer testing.
Model
Only after a mockup has passed initial customer testing and got the “green light” to move forward will I revisit the model and replace the hard-coded HTML for a real data model (e.g., database table) and fully functioning code. At that point, I will use the “feature flipper system” to do another round of selective usability testing with users before rolling it out to everyone.
Building mockups this way lets me
- show something “very close” to what will be delivered
- show something that looks “real.”
- iterate quickly with HTML
- quickly move from mockup to a functioning screen with little waste
Here’s a recent mockup I refined through this process for USERcycle:
Nice, but this won’t work here
The #1 reason given for separating design from development is that our developers can’t design, or our designers can’t do HTML/CSS. I used to be “just a developer,” too, but I taught myself just enough HTML/CSS (every browser has a “view source”) to put together some decent-looking pages. I know designers that have easily picked up enough rails and PHP to plug in mockups.
All the landing and application pages for BoxCloud, CloudFire, RunningLean, LeanCanvas, and USERcycle were done by me. If I could pull this off, so can you. Could a designer do better? Probably. Would it be worth the “iteration cost”? Most likely not.
Note: A reasonable tradeoff (if you can’t/don't want to design) is to hire a designer to develop an initial “design template” that you then own and maintain.