HTML prototypes are a big deal to the Diagram design team. We spend a considerable amount of time building, testing, rebuilding, polishing, and ultimately transforming static HTML prototypes from a low-fidelity interactive wireframe of sorts into a fully functional, CMS-backed website or web application. As such, we’re constantly looking for new ways to streamline our prototyping process, and over time we’ve learned quite a bit about what works best for our team and the projects we take on.
Staying focused
This is probably the most important tip to keep in mind throughout the entire prototyping process. Unspeakable amounts of time can be wasted without a clear idea of what’s important to the project at each step along the way. Of course, no two projects are exactly alike, and each team may use prototypes differently, but the principle remains: time spent obsessing over irrelevant details is wasted time. Before writing any code or organizing any directory structure, it’s important to have a clear idea of what a prototype is hoping to accomplish. If its only purpose is to test two slider interactions against each other, then rounding the corners of the pagination indicators is probably unnecessary. If it will ultimately be refactored before the final version, then the time spent obsessing over the perfect file hierarchy or dependency management system could be better spent on the CSS framework.
Of course, future considerations should be taken into account throughout every step of the prototyping process as well. At Diagram, we tend to develop our initial prototypes into full-blown websites, so things like file structure, CSS preprocessors, and dependency managers are sometimes decided upon initially if they’d be too much of a hassle to change later on. Overall, however, we try to agree on the intentions and scope of every prototype before anyone on the team opens a text editor or terminal window. Often, this means using styles and colors in the first iteration only to distinguish UI elements from each other, establish visual hierarchy or a grid framework, and identify interactive controls. Exceptions and unique considerations will arise from project to project, but ultimately, a clear focus in the prototyping process can be more effective than any other time-saving tool.
A prototyping toolchain for the modern web
With that last sentence in mind, there are now plenty of tools available to streamline the development process significantly. Here are a few we’ve found that best fit our team’s requirements:
Component library
Dennis Kardys has already written about this topic extensively from a design perspective, so it won’t be covered in much depth here. We’re still in the early stages of incorporating a centralized component library and dependency manager into our workflow, but so far, the advantages already outweigh the extra time needed to generalize jQuery plugins or OOCSS patterns. The ability to share components across all of our sites and update them from one central location is incredibly powerful. Instead of copy/pasting files from our most recent prototype into new ones manually, we now maintain a single version of a component on Github and use Bower to manage its dependencies and install it into new projects. Github’s README pages are also a much better place to store usage instructions and API methods than Slack discussions between coworkers.
Popular frameworks like Foundation and Bootstrap offer huge component libraries out-of-the-box, but after a few test runs with both of these, we’ve opted for a custom framework. If you want to know more about our approach to frameworks, Nick Melville has already discussed some of our reasoning behind this choice in his responsive frameworks article.
Pre/post-processors
The benefits and disadvantages of CSS (and, to a lesser degree, JavaScript and HTML) preprocessors has been the topic of countless articles in recent years, but they still deserve a mention here, as they have the potential to drastically transform the development workflow. On the CSS side of things, we tend to default to Sass, though we’ve actually gotten by using plain CSS for quite a while. In any case, when used responsibly, these tools can save hours of time and eliminate code duplication like few others can.
Boilerplates
Even with a centralized component library in place, most of our initial static prototypes are set up and organized the same way. As such, we now maintain a single, clone-able boilerplate repository that lets us create new prototypes from scratch in minutes. This isn’t a new technique by any means — popular tools like HTML5 Boilerplate have been around for years — but tweaking more generalized solutions like these to better fit our requirements has been an enormous time-saver in the early stages of a new project.
Experimenting is key
Like most every other practice on the web, no workflow is guaranteed to fit one team’s requirements as well as another’s. The tips and tools mentioned above have suited us well so far, but we still have plenty of room for improvement in our own prototyping process. That being said, there have never been more tools to help designers create responsive prototypes we can be proud of showing clients, and it’s likely they’ll only improve from here.
Do you have any questions for us about our website design processes? Do you want to know more about how our Discovery, Design, and Development services can revitalize your website? Please contact us to speak to a Solutions Engineer, or leave a comment below.
