A basic Lean Startup technique is doing the smallest thing possible to learn from customers. Applied to the product, this often times 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 building 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 in 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 of relying on barebone wireframes or sketches. While they are faster to put together, they require the customer to take a leap of faith on the finished product which I try and avoid. That said, given the 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 not just referring to design iteration, but the total time to deliver a finished, functional screen.

The mockup needs to minimize on 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.


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 need to 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” that lets us control who can see these changes. Once we are ready, we use this system to incrementally rollout a mockup (eventually the full-feature) to additional users.


I will then pick the “most impact-full” 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 hardcoded 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.


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 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 “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 really can’t/don’t want to design) is to hire a designer to come up with an initial “design template” that you then own and maintain.