From Wireframes to Code, Part I
Published: December 20, 2010
Within many companies, the use of wireframes in user experience design can be a contentious issue. People typically think of wireframes simply as artifacts designers create when generating design concepts, then later discard. Why not create a design artifact that is not disposable, but instead, one your team can convert to actual production code? Is this Holy Grail of the design process a good idea? Is it even possible? Or does the answer depend on the project, the team, and its agility? This first part in a two-part series takes an in-depth look at the process of converting wireframes to code.
My exploration of this idea began when a software developer—who was in the audience during a recent presentation on wireframing and prototyping—asked me, “Why can’t you just use the code from your wireframes as the basis for the final code?” This really great, straightforward question stuck with me for some time after the meeting. The real question was: Why waste time and effort on throw-away design artifacts? You could save everyone a lot of trouble by actually starting with working code. I was already aware of several software tools with which I could accomplish this goal and, in fact, had taken this approach on a recent project.
As I thought about the impact creating production code from wireframes would have on our UX design process, several deeper questions began to surface:
- Is there some reason the practice of using wireframes to create production code has not become prevalent? Could it be that wireframes, as a stand-alone deliverable, were due for extinction?
- If not, what important property has kept them a part of the UX design process?
- Is there a qualitative aspect of the design process that this new approach might bypass?
- If so, is there a compromise, or middle ground, that would let wireframing and coding take these missing components into account?
- How much of the debate is technical, and how much is process oriented or procedural?
In this first part of my series, I’ll take a close look at the role of wireframes in UX design, two different approaches to wireframing and their impacts on the development process, and help you determine which of these approaches would be better for a particular project. In Part 2, we’ll take a detailed look at what technologies and techniques actually producing the code requires.
But What Are Wireframes?
Let’s first take a look at wireframes and where they fit into the development process. If you’re new to wireframes, you should definitely read the excellent overview Traci Lepore wrote in a previous UXmatters column, “Sketches and Wireframes and Prototypes! Oh My! Creating Your Own Magical Wizard Experience.” We’ll use the following definition for the purposes of our discussion:
Wireframes are flexible design-creation artifacts that allow pattern exploration prior to deciding on a design solution. In essence, wireframes must provide an idea space for the development of designs.
The essential elements of wireframes are flexibility, exploration, and their pre-decision timing. Regardless of whether you plan to use wireframe code for production, these elements must be present or you’re not wireframing. (What would actually happen to your designs if they didn’t have these elements is well documented, but that’s a different story.)
Blueprints for Software
It might help to think of wireframes as equivalent to the blueprints architects create when designing buildings. There are many similarities between software wireframes and architectural blueprints:
- artifact representation—Both are simplified visual representations of a final product.
- information reduction—Both reduce complex information to demonstrate specific, salient points of a design.
- component annotation—Both make use of annotations to highlight or amplify details about a design that a designer cannot communicate through the visual rendering of a design.
These three elements communicate very clearly the purpose of both types of documents: to convey a design to a community of stakeholders without committing to the final product—again, creating that idea space I mentioned earlier. Their purpose is to collect ideas in a collaborative fashion, making a minimal level of commitment and maximizing flexibility. Consider the blueprint shown in Figure 1.
It’s possible to gather some very important information from this house ‘wireframe’ that you could never discern from the actual house. Notice, for example, that the designer has specified the layers of shingles, shimming, and very specific sizes for anchor bolts in the cut-away section. Also, look at the cutaway section of the roof, which the blueprint enlarges to provide detailed information. Architects have told me that the ability to convey these details is a critical property of blueprints. Now, imagine attempting to communicate this same information to a construction crew using a photo of an actual house.
The information a photo of a house conveys has much more richness and detail than a blueprint. However, it severely lacks flexibility as a communication medium. The inner properties of the structure are completely hidden to the observer. For example, it would be impossible to talk about the 2x4-inch plate the cutaway section shows in Figure 1.
Imagine attempting to build a modern skyscraper without blueprints. The architect would have a very difficult time discussing the specifics of the wiring with an electrician. The structural engineer might fail to communicate that a particular load-bearing beam must support a particular floor. This lesson from the world of physical architecture applies directly to software development. There are certain aspects of software that are extremely difficult to express through an actual product—such as its interaction design, purpose, and intended workflows—but wireframes handle this easily.
While my example describes the complex case of a modern skyscraper, in other cases someone might be building a prefabricated house or even a simple shed. There are many examples of structures that people have built using existing blueprints or without any blueprints. So, what is the difference, and when is creating blueprints a necessity?
Collaboration: The Dividing Line
The key concept wireframes revolve around is collaboration. Wireframes are essentially a team collaboration tool. They let designers, project leaders, developers, stakeholders, and users all see a project from a common standpoint.
The tools in wide use for wireframing—for example, Visio, OmniGraffle, and InDesign—not only allow designers to rapidly create and iterate designs, they also serve as a collection point for a team’s ideas. For projects with multiple stakeholders, collaboration is the glue that holds a design together. It’s axiomatic that an inability to adjust and gather input early leads to disaster later, no matter how you approach design.
While I’m describing the essential elements of what a wireframe does, I’m not ruling out any particular form of wireframe. I’m simply describing the basic properties a design artifact should have, regardless of whether you’ll reuse it. If your design artifacts lacked these properties, you might potentially leave some vital element out of the design process. These properties are universal, no matter what design approach or tools you use.
Remember, my original definition of a wireframe describes the need to create an idea space in which you can develop your designs. This important concept is the central thesis of this article. If you fail to create this idea space, your team’s ideas crystallize too early—likely on the easiest implementation. And if you show your users and stakeholders a high-fidelity mockup or the final product, they tend to focus on low-level details such as specific wordings, colors, and features.
While capturing a design, in reality, involves a continuum of approaches, let’s divide them into two general approaches for the sake of our discussion:
- integrated code approach—In this approach, you use the same artifact for design, then in the production code, as shown in Figure 3.
- separated code approach—In this approach, the artifact you create to communicate your design is separate from the final production code, as shown in Figure 4.
Figure 3—The integrated code approach
Figure 4—The separated code approach
At the beginning of my research, I fully expected the UX community to have a uniform view on this matter. However, its results revealed different camps with strong feelings regarding both approaches, as well as some people in the middle.
There were many who preferred the integrated code approach—even saying one should strive to create production code and skip wireframing altogether. But the purists on the side advocating for the separated code approach argued that there are many aspects of design that the integrated code approach leaves out—even if you do successfully solve the problem of effective collaboration. There is a danger you’ll focus on the wrong level of detail—or as one colleague put it, “You’re trying to row to the moon in a rowboat” with this approach.
Finally, there are those who take the middle ground. Their view is that the right approach—integrated code or separate code—really depends on many factors that make up a software project. I tend to fall into this group, having used both methods successfully. Let’s take a look at some of the pros and cons of each approach, then explore some factors that determine the best approach for a particular project.
Pros and Cons
There are major pros and cons to both approaches, and some of them are seemingly contradictory: Are you saving or adding time by taking the integrated approach? Do keep in mind that much depends on your implementation of an approach and the makeup of your project.
For the sake of brevity and to avoid redundancy, I’ll present the pros and cons of only the integrated approach here. Then, I’ll briefly describe the unique benefits of the separated code approach in a subsequent section.
Integrated Code Approach: Pros
These are some of the positives of the integrated code approach:
- decreased development time—Your team can skip the step of translating noninteractive pictures to functional code. Developers don’t need to keep going back to designers and asking them whether they actually meant for a button to do this or that.
- more agile—Going directly to code saves you time, because your team doesn’t have to do it twice. Developers don’t need to start implementing the design from scratch or spend time getting every pixel perfect. It’s already done!
- design control—The designer creating the production user interface has complete control over the final look and feel. This eliminates the thousands of little decisions developers must usually make about unknowns. Each pixel and behavior is exactly what the designer wants.
- design translation—Unlike with a separated code approach, where there are usually some differences between a wireframed design and the final product, with an integrated code approach, there is no translation of the design by developers, because the wireframe is the final user interface. The user interface the designer envisioned is the production front end. There is perfect translation from design concept to delivery.
- no technology barrier—How often have developers given designers lists of technical reasons they could not implement their perfect design? Creating the wireframe code in the environment of the production code is one way to minimize this risk.
- fewer requirements—Depending on where you stand, you might think of this as either a positive or a negative. Wireframes can become something like a requirements document. Without them, there may be no paper trail for requirements later on. However, there is a time saving in not creating them. Some companies require wireframes as part of their process; others might not care.
Integrated Code Approach: Cons
These are some of the negatives of the integrated code approach:
- increased development time—I know, I listed time savings under the pros. But, for some projects, I am suspicious of claims of time savings using this approach. Using the integrated code approach without getting the proper input from stakeholders could lead to massive amounts of recoding once the product team presents the application to stakeholders. (See also, dirty code. Enough said.)
- less agile—Reviewing and making changes to a design on the fly becomes increasingly difficult the more defined the look-and-feel and interaction design become. A designer attempting to make changes to final code during a live design meeting would either be unable to keep up with the team or slow their progress down.
- discourages design branches—One of wireframing’s greatest benefits is its ability to allow designers to develop multiple design options. When using production code, there would be less incentive to explore multiple designs and the scope of design options would narrow much earlier.
- dirty code—Many who question this integrated code approach feel that they would never get code that is good enough for production. They say, no matter what program a designer used to create the HTML code, it would always be throw-away code. The HTML code that some tools generate is less than developer friendly. The one exception I’ve seen to this: CSS-based prototypes. For these, the HTML code usually gets thrown away, but the stylesheets get reused as production code.
- wrong level of detail—Creating wireframes and prototypes for final code almost forces you to design something that looks perfect right from the start. Many designers would tell you to create wireframes with a certain amount of intentional ambiguity. (That’s why they’re called wireframes, after all.) In fact, many of the prototyping tools out there, like Balsamiq Mockups, provide widgets that intentionally look hand drawn for precisely this reason. Presenting designs without color or content communicates the flexible nature of the designs to stakeholders. This shows you’re still in brainstorming mode. Creating pixel-perfect designs right off the bat can focus the team too early on details like wording, content, colors, and minute interactions.
- decreased applicability—Many proponents of the integrated code approach have come from a Web development environment. Creating integrated code is trivial if you’re using HTML/CSS, but a lot of code is in other languages.
Separated Code Approach
I won’t go into too much detail on the pros and cons of the separated code approach, because they would be basically the converse of the integrated approach. The main benefit is, of course, their collaborative nature—this is their raison d’être. Creating wireframes means the design of artifacts becomes agile. It also ensures you can capture stakeholders’ numerous and qualitatively different requirements before committing to a design.
What Approach Should You Use?
So, given the preceding discussion, should you attempt to use the integrated code approach? I don’t think there is a single answer for every situation. There are many influencing factors to consider when deciding, including the following:
- project size—Projects that are larger in scope tend to require a great deal more collaboration and coordination between team stakeholders, including those in business, product management, design, development, and users themselves. If you find yourself balancing numerous requirements from many different stakeholders, the integrated code approach is probably not for you. Having fewer opportunities for collaboration and the code rework that might be necessary would negate any gains in speed.
- project importance—Are you working on a public-facing application with a large audience and involving high financial stakes? When you need to go through many iterations to nail a design, wireframes are your best bet, because of the flexibility they provide. Are you rebuilding an intranet in HTML/CSS, for which the tasks users need to perform are well known? Then, integrate the design and code.
- project agility—If you’re working in a highly agile environment, your first thought might be to skip wireframes and go right to code. That’s okay if you’re an adept CSS coder. But this might be your only chance to get stakeholder feedback. Keep in mind that using the integrated code approach could take you longer, if you have to start fiddling around with troublesome details. Remember, you’re not doing away with wireframing and prototyping—just keeping them in your production code. It’s always a challenge to keep pace in an agile environment. Don’t shoot yourself in the foot by handcuffing yourself to a slower design approach.
- team composition—What’s the makeup of your team? Do you have an army of coders who can help you crank out your design? Or are you an army of just one, who has to do all the design and code work yourself.
- your prototyping and design skills—If you’re a designer, you might be a better wireframer than coder. Your user interface might actually turn out worse if you try to code it yourself. If so, leave coding to an expert and go back to wireframing. If you’re a coder who’s trying to cover both roles, you might be a better coder than designer. Make sure to get input from a UX design expert often as you create your code.
- company culture—Some companies just want to get product out and don’t take time for a UX design phase.
While it is possible to create wireframes for desktop applications—think Visual C++ or Visual Basic—the issues around attempting to collaborate rapidly without wireframes in such environments are well known. In fact, one could even argue that these issues are what made the need for wireframing approaches apparent in the first place.
The Bottom Line
So, what’s the bottom line? It really does depend on your team’s skills, your project’s needs, your company culture, and a host of other factors. Keep in mind that—whatever design approach you decide to take and whatever tools you use to create your design artifacts and implement your designs—you need to protect the flexibility of your process as much as possible.