Where’s My New Prototype?: 8 Tips for Mitigating HTML Prototyping Startup Costs
Sketches can create immediate energy around an idea. After minutes or even seconds, you can communicate an idea and change a experience forever. Wireframes require more effort — and take more time — than sketches.
Wireframes: Draw, Export, Share!
However, a proficient UX wireframer needs no more than an hour or two to convey many ideas. A designer can assemble a sophisticated, low-fidelity layouts quickly, particularly when using familiar libraries (for EightShapes, that means using EightShapes Unify and other helpful kits). Need low-fi ideas fast? Got ’em, plenty of ’em. Draw in vectors, export to PDF, share or send. Done.
Can You Hold On a Bit? I’m Setting Up My Prototype…
For prototyping, the results aren’t always so instantaneous.
There’s the file & folder setup. There’s setting up a grid, reseting typography, and selecting libraries like 960gs, Foundation, jQuery, and even client-specific assets. And, if you’re like some of us at EightShapes, there’s the technical setup of Compass, SASS, Github, and — eek! — wrangling with the command line for this or that. All that setup, and you’ve not even typed your first <h1> tag or positioned your first element in a grid.
Not surprisingly, your project manager or client sponsor may be wondering: “What’s taking so long? Our ideas were pretty simple, and last time your wireframes were done in a day. Why do you need more than that to show me those ideas in a browser?”
Understand Your Startup Costs & Setup for Success
As designers, we’ve experienced this pain on numerous projects, usually those that need to build a design from the ground up and we expect to grow complex over time (as most of our projects do). As a result, we’ve learned some tips to balance the drawback of starting slow with the benefit of building a better, more effective foundation.
#1. Reset Expectations
If you’re a prototyping designer — especially a newbie with lower HTML & CSS proficiency — set expectations with your project’s manager that you’ll need a bit more time to render the first round of ideas. Maybe longer than wireframes, but not unreasonably so. It’s best to admit this light-to-moderate lag in delivering first drafts before you get started rather than a tensing up in a day or two when everyone’s looking for your outputs.
#2. Emphasize the Efficient Scalability
Building the first page — with its grid, typography, basic color, navigation, content — will take far longer than building page 2. And by the time you build pages 3, 4, 5, and beyond, so much code will be reusable such rendering new ideas, layering interactivity, and incorporating varied content will be well worth the effort.
#3. Conscientiously Sketch
The effort (in time) to encode design decisions in HTML & CSS is much higher than drawing a picture. So make sure that you’ve sufficiently, conscientiously sketched your ideas before going to code. You can’t encode chicken scratch, and will waste considerable time encoding half-baked ideas. Instead, know for sure where to locate elements, what your content is, and the range of variation you intend to explore.
#4. Start with Whole Pages & Avoid the Early Rabbit Hole
It’s tempting to add your page header, and then add header styling (via CSS) and even behaviors (via CSS or likely JavaScript) in the absence of everything beneath it. Then, a hour has passed. Or two. And by the end of an afternoon, you’ve got a header you only half-like with page content that’s worse than crude. Or even absent.
Any feedback you’ll get from others will be skewed by an grossly imbalanced picture, and your header design decision making may be just as uninformed. A better approach: frame the page, incorporate real content, and then balance tackling the details of various page regions in concert until the layout stabilizes.
#5. Align Team Behaviors to Divide & Conquer
If you are prototyping with others, separate concerns from the outset to avoid colliding on each other’s turf. Even in the context of one page, separations could include (even temporarily):
I own the HTML, you start the CSS.
I own the header and footer, you own the page content.
I own the responsive aspects of the grid’s columns and rows, while you own this and that individual bit of content.
One advantage that EightShapes gains by utilizing the modular Blocks prototyping framework is dividing responsibilities by component file assets, like:
I’ll own the HTML, CSS, and JS of components A, B, C and you’ll own the commensurate assets for components X, Y, and Z.
Even if we don’t use Blocks, we’ll often have dual CSS and dual JS files linked to a single page early on, only to merge them later when it makes sense.
#6. Command One Library (or Library Set)
One great freedom of HTML prototyping is choosing the framework(s) — jQuery, Foundation, SASS, 960gs, Twitter Bootstrap, etc — that work best for you, given your project conditions. These choices need not align with what the development team ultimately uses. However, learning framework nuances takes time.
We’ve invested in learning a few frameworks more deeply that we use most of the time. For me, personally, it’s jQuery, EightShapes Blocks and often Foundation. That way, I can set up page layouts quickly and render ideas efficiently.
#7. Organize Your Starting Points
We often use libraries over and over, and are as guilty as anyone of going into a previous project and copying the best of where that project left off. However, we pause intermittently to evaluate how different people organize code in files & folders, locate files here and there (especially, sprites!), and use up-to-date frameworks. As a result, subsequent projects share organizing tenets across team members and maybe even yield a location to “copy from here to start fresh.”
#8. Account for Time Learning Someone Else’s Code
Whether we are starting from a client-specific prototyping library of page types and components or diving into a prototyping project midstream, we often encounter each other’s code. And leave no doubt, everyone has their own style of coding and labeling.
Therefore, a designer new to a codebase will spend time reviewing examples and staring at a browser’s inspector to figure out how everything fits together. This cost is usually measured in hours or — in the case of complex libraries — days. Therefore, if you are adapting to a new codebase, incorporate that into your estimate of startup duration, and let your project lead know of that upfront investment.
Originally published at www.eightshapes.com on August 16, 2012.
