From Wireframes to Code, Part II

By Bill Schmidt

Published: February 21, 2011

I’ll discuss what types of prototyping tools would be best for your projects and how their use would impact your product development process.

In Part I of this series, I discussed two different approaches to wireframing:

  • separated code approach—in which the artifact you create to communicate your design is separate from the production code
  • integrated code approach—in which you use the same artifact for design and production code—creating code directly from wireframes

I examined the pros and cons of each of these approaches, as well as their impacts on the design process. In Part II, I’ll first explore what it would be like to instead go from code to wireframes. Then, for those of you who want to try employing a process flow that progresses from wireframes to code, I’ll discuss what types of prototyping tools would be best for your projects and how their use would impact your product development process.

What About Going from Code to Wireframes?

During a break from a long wireframing session, I was watching a snowstorm outside when the irony struck me. I had been thinking about how useful some particular wireframes had been in keeping our group together and assisting us in making design decisions. In fact, I could think of no other medium capable of both communicating design changes and facilitating the discussion that had kept the project moving along.

These wireframes had served us faithfully from the beginning—morphing from whiteboard to gray-scale outlines to the current set of colored, high-fidelity “infosthetics.” They were actually a composite of three different types of wireframes: garden-variety Visio wireframes, cannibalized screenshots of a prototype with Visio overlays, and screenshots of an actual second-level page. They even included a prototype from a usability test, in which we had embedded interactive wireframes.

The irony I felt had come from that last set of wireframes, which we had created out of production code. It occurred to me that this was really the exact opposite of what I had written in Part I of this series. Instead of going from wireframes to code, I had actually gone in reverse, from production code to wireframes!

After putting out the bonfire I had lit with the notes I’d planned to use for Part II, I pondered the meaning of all this. Would I need to redraw the flows from Part I? What impact would this new approach have on the process of creating code?

Lessons Learned

“Our goal is not to create perfect, pristine diagrams that adhere perfectly to design documentation guidelines. Our goal is to create a common idea space that facilitates team communication and collaboration.”

This episode taught me two important things about our work. First, real life is messy and chaotic. Software dependencies change, people move off projects, goals change. It’s one thing to draw flowcharts and diagrams and discuss the theories of proper information flow. But they don’t always reflect the vagaries of real life. I could draw out the process I’ve used on most of my projects with tidy linear arrows and boxes. But the bottom line is: you and your process have to be flexible and agile enough to adapt to the needs of any project.

Which led me to my second lesson: Although all of our theories really do help us think about our work in the proper way, at the end of the day, you really need to do whatever it takes to get your message across and move your team forward. To quote former Oakland Raiders head coach Art Shell, “Just win, baby.” Our goal is not to create perfect, pristine diagrams that adhere perfectly to design documentation guidelines. Our goal is to create a common idea space that facilitates team communication and collaboration. The bottom line is that your diagramming software, wireframes, and prototypes are all simply tools in your toolbox.

One final note on this topic: One reader who commented on Part I of this series posted an interesting and relevant link. Jussi Pasanen has created a very interesting application called Wirify, which actually does convert production code to wireframes. Figure 1 shows before and after images.

Figure 1—The actual page and a Wirify wireframe of CNN.com

Wirify wireframe of CNN.com

Wirify allows you to convert any Web page into a wireframe with the simple click of a browser toolbar button. Since I had just finished writing this first section of Part II, I got pretty excited about this application!

The existence of Wirify does prompt this process question: When in the development process would one use an application like this? Perhaps you could use it to establish a baseline when progressing from one version of a site to another? Or for comparative purposes? I’m hoping Jussi and others will weigh in with ideas for how to use this innovative application. Thanks for sharing it, Jussi.

From Wireframes to Code: Considering the Tools

“Let’s focus on the integrated code approach and look at the technologies that are available for those who want to use it….”

Now, let’s focus on the integrated code approach and look at the technologies that are available for those who want to use it, then delve more deeply into the characteristics of these tools. How do you start? What are the best tools? What should you keep an eye out for?

Tradeoffs

When considering what tool to use for creating code, here are some factors to consider:

  • learning curve—Some tools are just easier to use than others. If you’re an information architect with little programming experience, you may want to choose a tool that emphasizes ease of development. But keep in mind that this ease may come at the cost of more unwanted code.
  • development curve—Even if you do have coding skills, it just takes longer to create code with some tools than others. For example, you can use Flash to produce some very interactive prototypes, but creating those prototypes can be very time consuming.
  • coding interaction—Bottom line: You don’t get anything for free. You can code interactions from scratch, which gives you a richly interactive, but time-consuming-to-create prototype, or you can have agility and create a quick-and-dirty prototype whose functionality you’ll have to recode later. There is no perfect solution—yet.

Constraints

There are many viable prototyping tools. Which one should you choose? Here are several types of constraints that can help you narrow down your choice, including the following:

  • technology boundaries—These are probably the most important and restrictive constraints: the tool forcing the project to adapt to a technology or environment. After all, we are talking about creating production code from wireframes. An application that simply doesn’t let you create production code that’s appropriate for your context is a show-stopper.
  • technology dependencies—All applications have technology dependencies. And these have a tendency to change, which can come back to bite you later in the development process. I’ve heard stories of projects where software dependencies changed near the end of the development cycle. Using the integrated code approach, in this case, turned out very badly, because the team was forced to step back to square one. While your team might be able to handle this problem easily when using the separated code approach—where wireframes and code are independent of one another—if you’re too far along in your development process using the integrated code approach, starting from scratch could be a serious issue.
  • limitations of the coder’s ability—Knowing your own and your team’s limitations can help in narrowing down the selection process.

Capabilities: A Continuum

“Certain dimensions of a software tool’s capabilities interact with one another, so they may also limit what tools are available to you.”

Certain dimensions of a software tool’s capabilities interact with one another, so they may also limit what tools are available to you. Consider the following three dimensions of wireframing tools, which Figure 2 represents in a graph:

  • flexibility—How broad are a tool’s applications? Paper-and-pencil sketches apply in all situations; a specialized Delphi prototype may apply in only one.
  • agility—How well does a tool facilitate rapid design iterations? A complex or cumbersome tool can hold back your progress.
  • fidelity of functionality—How close can your initial wireframes come to the final product’s functionally? How many of its interactions can you add to the prototype? While it’s almost impossible to add functionality to a paper prototype—although designers have simulated interactivity—it’s definitely possible with a C++ prototype.

Figure 2—Wireframing tools’ capabilities

Wireframing tools' capabilities

This graph depicts the characteristics of a representative sampling of wireframing tools in three dimensions—for example, Visio represents all wireframing tools that let you create wireframes with limited functionality, including Balsamiq and OmniGraffle Professional. The X axis shows fidelity and functionality; the Y axis, agility; and the vertical Z axis, applicability. The gray area in the middle represents the sweet spot, encompassing the tools most commonly in use for wireframing. These tools provide the best balance of flexibility and agility for a given level of functionality.

As the graph shows, paper-and-pencil sketches are most agile and flexible, but also have the lowest fidelity. On the other hand, near production-quality software prototypes have low agility, but almost complete functionality.

I’ve oversimplified the graph in Figure 2 to demonstrate a principle: the inverse relationship between agility and functionality. Plus, by definition, an increase in functionality decreases the degrees of freedom for a design. This makes perfect sense, because you have to program the functionality somehow or at least think about the additional interactivity.

In this graph, the height of each column depicts a tool’s flexibility, or applicability. For example, you could use paper-and-pencil sketches for any project, but a Delphi prototype might be applicable to only a specific project, in a specific environment. Notice how flexibility also decreases as interactivity, or functionality, increases. Thus, a three-way interaction exists between these three different dimensions—that is, both agility and flexibility decrease as you add richer functionality to a prototype, creating the technology slide shown in Figure 3.

Figure 3—The technology slide

Technology slide

In my opinion, the one exception to this rule that there is an inverse relationship between agility and flexibility versus functionality seems to be Flex. In the past, I’ve successfully used Flex to create production code, and it was extremely agile. It did score lower on the applicability scale—somewhere between HTML and Software Prototype. There are many other tools out there that don’t appear on this chart. However, in general, I think the basic principle holds up: there is an inverse relationship between agility and flexibility versus functionality. You can’t get something for nothing.

There is an inverse relationship between agility and flexibility versus functionality.

As I created these graphs, I wondered what a graph of a technology’s effect on an idea space would look like. If you think of the size of an idea space in terms of the degrees of freedom that are available for different thoughts—the larger an idea space, the more thoughts it can simultaneously accommodate—the graph of a technology’s effect on an idea space would look similar to the technology slide, as shown in Figure 4.

Figure 4—Graph of a technology’s effect on an idea space

Graph of a technology's effect on an idea space

As the graph moves from the upper left, or high agility, to the lower right, or high fidelity and functionality, the size of the idea space shrinks—meaning you would have a lower degree of design freedom. For example, you could design anything with paper and pencil—a rocket, a dinosaur, a time machine—but as you add functionality, you become restricted by the technology. (Unless you think you actually can prototype and build that time machine you drew on the back of a napkin!) So, there is a direct correlation between the size of the idea space and the flexibility of the design medium.

The Perfect Prototyping Tool

“What would the perfect prototyping tool look like? Its driving philosophy would be to maximize the idea space while enabling you to create clean, final code.”

Keeping all of these factors in mind, what would the perfect prototyping tool look like? Its driving philosophy would be to maximize the idea space while enabling you to create clean, final code. So, if we could wave a magic wand and create the perfect tool, it would have the following characteristics:

  • completely usable by designers
  • completely usable by coders
  • agile
  • supports different levels of fidelity—for example, switching from Balsamiq-like, low-fidelity drawings to production-ready user interfaces, including reskinning
  • creates clean code
  • lets you switch from a design mode to a develop mode with the press of a button
  • supports a wide variety of technologies, including the Web, C++, Java, and XML

That’s my wish list. I’m hoping some of you will add your wishes through comments. Who knows? Perhaps one of the prototyping-tool companies might take notice.

Impact on the Development Process

“The designer would create wireframes, have stakeholders review them, and refine them. … The designer would then hand the prototype off to the developer, who would put all the final code in place.”

Finally, what impact would this perfect prototyping tool have on a project’s software development process? Well, let’s first assume our hypothetical project team includes both a designer and a coder, and they would both use the same tool. The designer would create wireframes, have stakeholders review them, and refine them. Once the design became solid, the designer would create to exact specifications what would become the product’s final user interface. The designer would then hand the prototype off to the developer, who would put all the final code in place. Voilà—all done.

Slight plug here. For my money, Flex really seems to approach what I would call the perfect prototyping tool. The only two characteristics from my wish list that it lacks are different levels of fidelity and support for a wide variety of technologies. The latter deficiency is something of a show-stopper for most product teams, because Flex requires the use of Flash. I’ve also heard from some that it creates dirty code, although I have not yet seen this on any of my own projects.

This wireframes-to-code scenario poses a host of questions: How would you handle design rework later in the development process? Would there be a tendency to jump right to code or undervalue the role of the designer? I would love to hear the thoughts of readers on this.

What’s Next?

We’ve now covered much of the theory and process behind creating code from wireframes—and vice versa. In the next part of this series, we’ll take a look at some actual code to identify the things to look out for when going from wireframes to code.

Now that you’ve read Part II, I hope you’ll share your thoughts on this approach in the comments. Stay tuned! In Part III of this series, which I’ll coauthor with Martin Lambert, I’ll analyze some actual code we’ve created using a number of wireframing tools.

8 Comments

We use an open source content management system, in which new features can often be developed with a minimum of coding by choosing the right module or set of modules to add to our setup. I hope we can turn to creating prototypes with our CMS, testing them, then refining the user interface and features as necessary by modifying the production code. I know of a number of private shops—I work for a governmental agency—that prepare their prototypes with Drupal. It seems to work very well for them. I hope we can reproduce that success.

By the way, Bill, there’s something confusing about Figures 2 through 4 and the portions of the text that refer to them. In the figures, you’ve labeled the Z-axis “Flexibility,” but in the body of your article you consistently refer to that property as “Applicability.” Which should it be? And if it is “applicability,” in what sense do you mean that? I don’t have a clear grasp of the concept you intend “applicability” to convey here.

Hi @Clifftyll—Thanks for the comment! Your project sounds very interesting. We are investigating a similar process here for an application that has a core set of functions that vary slightly from customer to customer in a modular fashion. I’m very curious about your CMS system and the details of how you intend to incorporate this into your development process. Also, how do the UCD principles merge with the CMS system? Are there ways in which the CMS enhances or hinders the process?

I had gone back and forth between using applicability and flexibility in this article, and finally settled on flexibility. The concept revolves around limiting or restricting the situations in which you can use, or apply, a tool. The term applicability seemed a little confining to me, hence the switch to flexibility. In the context of the article, I would think of them as interchangeable. It’s basically a measure of the universality of a tool.

Great, very detailed article! A really good insight on the benefit of prototyping.

Regarding the best prototyping tool, I’d say Justinmind comes really close. ;) But I’d also add an extra point that’s essential in my opinion: the need for usability testing. I think that’s an essential part of prototyping—to thoroughly test your prototypes to best serve your future users.

@etienne,

Thanks for the positive feedback. I’m glad you liked the article. I think you’re really going to like Part 3 of this series as well. My co-author for the next segment and I just met about it, and we have a really great idea for the next installment, where we will be looking closely at the conversion process.

And thanks also for the pointer toward Justinmind. We are in the process of evaluating tools for the next installment, and this looks like a contender.

I must now hang my head in shame, as you have very correctly pointed out that I have left off usability testing as part of the process. This definitely cuts me to the quick, as I have been a very loud evangelist of usability testing in every job I’ve ever had, almost to the point of obnoxiousness—which is what it takes in a lot of cases. And yet, I completely neglected to talk about it when given the UXmatters podium. I hope you will allow me to make up for it by referring to this comment in the next installment and bringing attention to my grave oversight. Shame, shame, shame.

Thanks again for the note!

Hi Bill, thanks for another great article and for your Wirify mention!

“When in the development process would one use an application like this? Perhaps you could use it to establish a baseline when progressing from one version of a site to another? Or for comparative purposes?”

The core idea of Wirify has proven surprisingly versatile, and people have successfully used it for early inspiration, benchmarking, and concept work, as well as in the later design, documentation, and testing stages of their projects. As soon as you have some real HTML, you can use Wirify to “step back” into lower fidelity, and study the layout and structure of your pages without being bogged down with the detail.

You can certainly use Wirify for comparisons, too; here’s one example. I see this being useful in the earlier stages of a project.

With regard to the commercial version, Wirify Pro, we’re positioning that specifically for redesign projects. Rather than starting completely from scratch, you can turn your existing key pages into editable OmniGraffle or Balsamiq wireframes and take it from there, saving some significant time in the process.

More generally, your wish list for the “perfect prototyping tool” is really interesting. At the same time, it sounds a bit like the Holy Grail that the industry has been trying to come up with for years, with the latest contenders being major products like:

  • Microsoft Expression Blend—with “seamless design and development workflow” from a “SketchFlow prototype” to a working .NET application
  • Adobe Flash Catalyst—from Creative Suite content to Flash applications—“interaction design without writing code.”

These highly integrated environments promise great leverage and high efficiency; however, this comes at a price. To realize these benefits, you must consistently use these environments for most things, which limits your ability use other tools as part of your workflow. This, in turn, can significantly reduce your idea space.

As an aside, there’s another interesting dimension to this discussion in the form of specialized generative tools that allow you to convert your interactive prototype into a real implementation:

  • IntranetFactory’s Modeler for SharePoint allows you to design and “build a SharePoint site independently of the real implementation.”
  • SoftwareServant automatically “builds applications from a Microsoft Word system specification” and a Balsamiq Mockups prototype.

These tools can be highly useful in specific domains; however, I believe the potential downsides of highly integrated environments listed earlier apply here, too.

“For example, you could design anything with paper and pencil—a rocket, a dinosaur, a time machine—but as you add functionality, you become restricted by the technology.”

I believe this holds true for any set of tools, not just paper and pencil. The tools that we use shape and constrain the outcomes we produce.

To me, something that can create “production-ready user interfaces” and “clean code” is not a prototyping tool anymore—it’s something else; and while it would be great, it probably won’t become reality anytime soon. And when it does, I hope it’s a series of sharp, independent, but highly interconnected tools from a number of different vendors rather than one monolithic environment controlled by a few big players alone. :)

Thanks for a really interesting series, Bill. Let’s keep the conversation going!

PS—I completely agree with Etienne on the importance of usability testing, regardless of the specific toolset that you’ve chosen.

PPS Disclaimer: I don’t have personal experience in using the products I’ve mentioned—except Wirify, of course—but I have been following their development with great interest.

Hi Jussi,

Thanks for the great feedback It’s great that Wirify can be used for so many purposes. I was really struck by the breadth of use in the process you cite in your examples. I wouldn’t have expected that type of usage through such a broad spectrum of the development cycle. Another application for Wirify occurred to me as I looked through your examples, which is the ability to convert several designs to create a “blind taste test.” One could compare the wireframes of several well-known brands based on the layout alone, removing any brand bias.

Thanks also for the pointers toward those two applications. We will definitely take them into consideration as contenders in the next installment of this series. We will be comparing the code produced by several applications in a Production Code Death Match. Stay tuned for more wireframes-to-code fun!

“To me, something that can create �production-ready user interfaces� and �clean code� is not a prototyping tool anymore—it�s something else;”

Hmmm… This statement intrigues me. From a process perspective, it certainly could open the door to jumping past important design steps. Many folks are already doing this to a certain extent with HTML prototyping. In fact, I’ve spoken with leading designers who now use HTML/CSS for creating hybrid prototypes/production code, which is effectively the same thing at a much more basic level. The problem is extending the ability to move freely between prototyping and production once you get into richer functionality—that is, we basically want the tool development companies to make the Technology Slide less steep at the low end, if you will.

Thanks again for the great comments, Jussi. I will probably address some of these in more detail in the next article.

Bill

Hi again, Bill, and thank you for your response! Just a quick followup on the statement you highlighted:

To me, something that can create �production-ready user interfaces� and �clean code� is not a prototyping tool anymore�it�s something else.

I feel that big part of the value in creating prototypes comes from their throw-away nature. They help you explore different ideas and solutions, but at the same time, prevent you from getting too attached to these, since you know that the prototype is only temporary.

The risk in the hypothetical “beyond-prototyping” tool is that it’ll change our perception of the prototype by making it much more permanent. This in turn requires us to think about all the additional realities involved in creating a production-ready system that we could previously freely ignore when working on prototype-level only. I believe that many of the greatest innovations come from ignoring the reality and feasibility altogether, and just pursuing the original idea with great persistence.

Hope that makes sense, and looking forward to the next installment!

Hi Jussi,

Good points. For me, there are really two parts to this. First, I think this is true for the state of the art for prototyping tools right now. But what if some of the companies created the ultimate prototyping tool that allowed one to create prototypes as easily as PowerPoint documents? This would allow easy changes and branching of the design ideas early on.

The second point is more serious to me. That is, the level of fidelity of the artifacts being designed. Regardless of how many design branches one can create, showing the stakeholders a finished-looking document will have an impact on the expectations of the stakeholders and users.

I wonder what impact an ultimate prototyping tool would have on the design process? Let’s say you could create multiple iterations of a finished-looking design to stakeholders? Having multiple designs to present to them would certainly indicate the transitory nature of the designs to them, don’t you think? Hmmm… Food for thought.

Join the Discussion

Asterisks (*) indicate required information.