How I Build Mockups

Written by Ash Maurya

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.

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 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.

View

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.

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 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.

Become a Practice Trumps Theory member
(it's free)

Get access to more tactical content, videos, and hands-on techniques for systematically building a successful product...

  • http://techsassy.blogspot.com/ sassyboy

    I have downloaded a few freely available css templates and modify those to build the mockups, which tell a story. looks neat enough and involves lesser html css coding..

    [Reply]

  • http://www.appsdns.net/ Andrew Chilton

    Yeah, I generally do a mockup with my application and just some sparse HTML to make it ‘there’ first, and ‘pretty’ and ‘correct’ later. I already did what you suggest with the design and bought one from a designer, which has all the elements in it I’m likely to use (initially anyway, more can come later when I actually need them).

    [Reply]

  • Jason McGhee

    As someone that’s not able to write code efficiently work with html, I find that PowerPoint works great for showing a concept and conveying my needs to developers.

    [Reply]

  • Anonymous

    Hi Ash,

    We’ve just launched a new app that might add a new approach to how you do mock ups.

    It’s a browser based design and dev environment that allows you to create full production ready html/css (think Coda in the cloud) but at the same time gives a unique method for creating HTML/CSS mock ups really (really…) quickly.

    Check out http://buildorpro.com/guide/mockups_vid2.php for an overview

    We’re in beta at the moment but if anyone would like an invite: http://buildorpro.com/beta_signup.php

    Cheers,

    James @ Buildor

    [Reply]

    Ash Maurya Reply:

    Looks very promising James… I will give it a go with the next screen I do.

    Thanks for sharing.

    [Reply]

  • Steve

    When taking about controllers, your use of the word “layout” threw me. I thought this meant visual layout. I would prefer the word sequence or flow, as your subquote uses

    [Reply]

    Ash Maurya Reply:

    I agree. Especially in rails, layout means something specific – So I got rid of it :-)

    thx!

    [Reply]

  • Steve

    I do like this article which reveals your techniques. Please also write how you plan new controllers & models before you code. Do you do it all in your head, or do you make outlines of workflow using narratives in wordpad or on paper?

    [Reply]

    Ash Maurya Reply:

    I will sketch some more complicated flows on paper first…but I find myself jumping to code more often and refining on screen. Sometimes, the amount of thinking is simply: “I need some kind of wizard flow to walk the user through this task”. I might break it into 3 steps, wire the controllers and start working the views.

    I usually defer all model implementation till I build the first pass of the view first but some decisions have to naturally be made while you are building the structure of the app. In LeanCanvas for instance, we had to decide the container hierarchy of Products -> Canvases -> Experiments -> etc.

    [Reply]

  • http://feint.me feint

    “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. ”

    I’ve never had a problem with any of the mockups I’ve done in Photoshop – never has there been a situation where it couldn’t be recreated in css/html. I good designer knows the limits of photoshop.

    Your approach is similar to whats done at 37signals – although it seems to work well, I don’t think it produces the nicest looking apps.

    [Reply]

    Ash Maurya Reply:

    “A good designer knows the limits of photoshop”

    That’s the key point. I am not advocating developers take over design, or designers take over development, but rather that there should be some overlap and understanding of the how the work flows and try and minimize on waste.

    [Reply]

  • Pingback: Creating a mockup in anything other than the final technology in which the product is delivered creates waste. | Startup Bites

  • http://twitter.com/benbjohnson Ben Johnson

    Creating mockups in HTML/CSS works okay if you’re proficient but it cuts many important people out of the loop. Graphic designers, interaction designers, and product owners should be able to create (or at least modify) mockups easily so they can communicate their ideas as well.

    It also works against Test First Development principles because you’re building out functionality for a mock that will have to have tests added on later.

    In an ideal world, I believe that mockups should be testable using the same tools as your app. For example, I should be able to run a Cucumber test against my mockup that also works against my application. That way my test is written before my code and it requires that I keep my mockup in sync with my application (or otherwise my tests fail).

    [Reply]

    Ash Maurya Reply:

    Ben –

    Prior to the HTML/CSS stage, I am okay with relying on a paper sketch or wireframe that others can freely iterate with. What I am against is creating other forms of “higher fidelity” mockups which is a form of waste. This is something Ryan Singer also recently covered in a talk on the 37signals design process.

    I agree with you on testing using the same tools as the app and once the “creative” process of sketching and building the initial html/css screens is done, I am all for plugging it into your test framework of choice.

    Cheers.

    [Reply]

  • http://www.facebook.com/profile.php?id=544210479 Rahul Chakrabarty

    Ash – I have been following your blogs for a while and I must say I found many of your articles very informative from a start-up standpoint. I am working on an MVP and using HTML/CSS to develop the pages. Except for the landing page, most pages have demo data.

    Is it recommended to use mock ups to provide demo to Customers (Business/Companies) as I am building a B2C related site. My confusion is my demo data is made up of different product images and mock-up data, and I am not quite sure if that’s a good idea.

    [Reply]

  • Pingback: How We Build Features – Expanded (Q&A)

  • Darel Johnson

    Ash, I normally use Balsamiq for mockups. I usually like to start out this way before I code high fidelity prototypes. Is there a problem with my approach?

    [Reply]

    Ash Maurya Reply:

    Not at all. I also start with something low fidelity at first – typically a paper sketch.
    However, for the reasons outlined above, I try and show the customer something as close to the final product as possible.

    [Reply]

  • Pingback: How I Build Mockups – Ash Maurya : Knowledge Base