From Wireframes to Code, Part I

By Bill Schmidt

Published: December 20, 2010

“Why not create a design artifact that is not disposable, but instead, one your team can convert to actual production code?”

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.

The Question

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

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?

“The essential elements of wireframes are flexibility, exploration, and their pre-decision timing.”

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

Their purpose is to collect ideas in a collaborative fashion, making a minimal level of commitment and maximizing flexibility.

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.

Figure 1—Portion of a building blueprint

Blueprint

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.

Figure 2—A house

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

Two Approaches

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

Integrated code approach

Figure 4—The separated code approach

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

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

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

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.
“If you find yourself balancing numerous requirements from many different stakeholders, the integrated code approach is probably not for you.”

Finally, proponents of the integrated code approach usually talk about it in terms of developing Web pages—that is, HTML/CSS code that is enhanced with perhaps JQuery, JavaScript, or other code. The more specific your application is to a particular platform, the more difficulty you would have employing the integrated code approach.

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.

6 Comments

Thanks for a great and very detailed post, Bill.

Given the headline “From Wireframes to Code,” I can’t help but pitch our new little tool Wirify. What it does is essentially the exact opposite, from code to wireframe. I hope some of your readers will find it useful!

Cheers, Jussi

Hi Bill. I saw mentioned in your article that a coded prototype can discourage design branches. This feels to me to be a critical and overriding drawback. Sinking the effort to create a coded prototype seems fundamentally at odds with your stated need to create an idea space to iterate design.

Recently, I worked on a project where we used Balsamiq Mockup wireframes to proceed through several iterative design reviews. In the final review, a major dependency on other software arose, and we needed to completely redesign some key workflow steps to accommodate it. In the schedule we had left, there would have been no time to recode as well as redesign.

I can see value in an integrated approach only in a very well-known space, when all technical and design issues are well understood up front. It would be a situation where creating an idea space and iterating are not seen as necessary. Not a very interesting project, in other words!

Hi Josh—Great points! Your observation on the tension between the code and idea space really gets at the heart this article. The additional requirement for creating final code can have only a neutral impact on the creative process at best. However, all things being equal, this may be a risk some are willing to take for the benefits of the integrated approach—such as speed, design translation accuracy, and expediency—if conditions permit.

The story you provide is another great example of the dangers of the integrated approach—that’s one of the cons I hadn’t thought about. It definitely demonstrates how locked in your design is with the integrated approach.

Regarding your last paragraph, while the hardcore integrated developer might agree with the first statement on the technology issues, they would probably argue that the integrated approach could be well suited for projects requiring creativity and design iterations. For example, someone creating wireframes for a straight HTML page would simply create the wireframes in Dreamweaver and iterate until the design became stable. This approach allows both a fluid design stage and morphing to a more crystallized form later. But as you pointed out, this is possible only under certain conditions. This is actually something I’m going to address in detail in Part 2 of this series. Thanks for the great discussion!

Hi Bill, and thanks for a great article!

I’m with you on taking the middle ground between the “integrated code” and “separated code” approaches. And it really does depend on the project.

This said, I also think that a “production-ready prototype” is a bit of a holy grail in IT. It may be a good goal, but I’ve never seen one created in a real-world project. If the prototype is good—however defined—it gets iterated and refactored until pretty much all the design and implementation details have been changed and tweaked, and only the concept remains of the original. And if the prototype is bad, it quickly ends up in the recycle bin, which is not to say it didn’t add value to the project.

Overall, I feel that wireframes and prototypes are both tools for sketching, communicating, thinking, and exploring rather than something that should directly form part of a final, functioning application or Web site.

Finally, a semi-related plug: given the title of your article “From Wireframes to Code,” I must mention our recently released tool Wirify, which allows you to go the other way “from code to wireframes” and re-interpret an existing Web page back into a wireframe. I thought your readers might find it useful.

Looking forward to reading the second part!

Regards, Jussi

PS: Ryan Singer of 37signals wrote a good post on “Refactoring for Designers” last week. It’s worth a read.

Hi Jussi,

Thanks so much for sharing the link to your application. What a great site! Perfect timing, too, as I was going to talk about exactly this in Part 2 of the series. I hope you won’t mind if I mention this in the next article.

I also agree with you that the production-ready-code prototype is something of a grail. There are a couple of aspects to it. I’ve spoken with some developers who say that the only wireframe / prototype code they would consider using would be the HTML / CSS prototypes. Even then, they would probably consider using only the CSS. I have done it successfully with FLEX and did not appear to have any throw-away code whatsoever. Perhaps I just lucked out and had the perfect environment, tool, and team to make this work. I was hoping some of the readers would chime in with success stories using other tools. I know of a number of tools that claim to do this, but most of the feedback I’ve seen is that they produce too much junk code.

PS: BTW, that was a great article by Singer. Interesting peek behind the scenes.

Hi Bill,

Thanks for having a look at Wirify and your feedback! By all means feel free to include it as an example in your next article.

Interesting point about Flex, I don’t have personal experience in it, but I wouldn’t be the least surprised if some environments had an edge in late-stage prototyping over others. Speaking of which, I’d love to explore Microsoft’s Expression and SketchFlow, too. They sound really good in principle, and it would be interesting to see how they fare in a real-world project.

Cheers, Jussi

Join the Discussion

Asterisks (*) indicate required information.