Adaptive Information Design and the Box Diagram

Once your team understands the requirements for an entire project, you can sort the same requirements cards within a single view to understand how best to implement them. An example of the output of this exercise is shown in Figure 2.

Optionally, my design team might start working on the design ourselves—not just to create a pretty user interface, but representing it at as high a level as is practical—as a box diagram if possible—and explaining our approach and assumptions. If we find these are mistaken, we can correct them early on.

Tools for Box Diagramming

Fundamentally, box diagramming is exactly what it sounds like. You are going to diagram, using boxes. These boxes are

• just boxes—Create only rectangles and squares.
• any size you need—However, decide early on whether size should be purely representational or have some other meaning such as importance or expected usage rate.
• labeled, not designed—Use simple titles, perhaps a few bullet points, or iconic representations of content such as arrows or cartoonish images. Do not draw or write anything to be like real content.
• coded—Use boxes of different colors, stickers on the corner of each box, or other methods to categorize each box type—even such simple categories as items on every page or items only on this page—so users can perceive and understand the coding at a glance.

There are several ways to do this, but none is universally better than the others. In fact, I use all of them at different times, on different projects. Let’s consider each of these.

Drawing and Whiteboards

Use a whiteboard or any surface you can draw on. Or just sit at your favorite coffee shop, drawing on your notepad. Some benefits of box diagramming are that it’s simple, fast, and understandable at a glance, so it’s great for collaborative exercises. Get a team together and draw big, so you can get everyone’s input. You don’t need to prepare for this. If you’ve left all of your design supplies at home, just clear some space on a whiteboard or get some chart paper and markers. Start drawing simple boxes.

Post-it Notes

My favorite mode of collaboration by far is using sticky notes. Practically, you’ll probably end up mixing methods. Place notes on a whiteboard or piece of chart paper, then you’ll end up bounding, labeling, or adding some items by drawing directly on it, as shown in Figure 3.

As you can see, the sticky notes are not only positioned to represent the content and its relationships, but have different colors and sizes. This is important because box diagramming is all about organizing the boxes of content according to the first two aspects of the hierarchy of visibility: Position > Size > Shape > Contrast > Color. You’ll address shape, contrast, and color in the next step, when you actually create a detailed user-interface design based on this information-design work.

However, since we’re now most concerned with position and size, the sticky-note method works great. You can move, remove, or replace notes. Because they are paper and cheap, you can fold, cut, tear, tape up, and scribble on them. For this reason, I strongly prefer using Post-it Notes to simply drawing boxes on paper or a whiteboard. Of course, you’ll need a piece of chart paper or a whiteboard to put the Post-it Notes on. You should feel free to draw with markers to define the outer box, label the page, or draw arrows to show process. Include some tape in your design supply kit. You’ll eventually find a surface to which the notes won’t stick—or perhaps you’ll move them around so much that you’ll need to add more stickiness to them.

Scissors and Tape

You can use this same basic scissors-and-tape method for existing products or revisions to first designs. Print out the designs, then cut out their components with a pair of scissors or an X-acto knife. Choose a work area such as a whiteboard, move components around, then tape up each box of content where it is needed, as with the Post-it Notes. Figure 4 shows an example of this work in progress.

Often, it’s best to print out two or more copies of a design, enlarging the design so it’s easy to see and handle. Don’t hesitate to modify the cut-out shapes, folding or cutting them to make them smaller. Draw on the whiteboard or chart paper if you need to indicate that an element is bigger or otherwise different. Feel free to use other methods of representing new or very different components—such as supplementing the design by adding Post-it Notes.

Using scissors and tape is great method for any number of complex, organizational tasks, not just page design. My team once needed to revise a document that included 10,000 requirements. This went poorly almost immediately when we tried using spreadsheets, and it was impossible for us to collaborate, so I instead had the team print everything out, cut out each requirement, and group them on a wall. Your workshop and design kit should always include scissors and tape as well as Sharpies and Post-it Notes.

Digital Drawings

Digital renderings don’t lose their stickiness. Plus, you don’t have to go to the store to get more sizes and colors. Otherwise, drawing box diagrams in digital spaces is much the same as the previous methods.

While creating drawings by hand on a pen tablet or touchscreen is possible, they may not very readable, nor is this method efficient. I try to make sure everything is legible, so draw simple boxes and type inside them using an application’s drawing tools, as shown in Figure 5.

Of course, this isn’t very demanding graphic-design work, so you can use any application you like. I use Adobe InDesign as my default drawing tool, but you can do this in pretty much any application. PowerPoint is a pretty good choice if you have limited resources or need to share an editable version of the work with nondesigners.

Digital tools also work well for cutting up existing designs—especially when you don’t have access to the original design documents or they’ve become irrelevant because of changes in production over time. Simply use the cropping tools—and even PowerPoint has these—to create a box for each element. Then, rearrange the boxes in whatever way you want. Stretch or compress them or scale them to fit, just as you would with a Post-it Note design.

Using a similar style throughout can be helpful in communicating that an information-design level exists and in explaining the structure of high-fidelity designs to the team. All of this helps communicate the modularity, reusability, and data-driven nature of your design.

My favorite method is to create boxes—just as I would for a normal box model—but make them translucent so the team can see the high-fidelity drawing behind them. It’s usually best to place labels off to the side for readability, as shown in Figure 6.

Design-Studio Methods

One way I use this whole concept of cutting and pasting boxes is in the context of design-studio methods. I think studio methods result in a sort of competitive / collaborative process of design. A number of individuals or small teams come up with concepts for a new product or a specific page, problem, or widget. Then, everyone gets back together to discuss and review the ideas.

But here’s where the overlap with box diagramming comes up. Because no design is so perfect that you should adopt or reject it as a whole, as the creative director, working collaboratively with the whole team, I’ll pick and choose which elements are best, then mix and match them in new designs.

Often, it’s best to do this live, using scissors and tape. Then, I’ll give the new pasted-up diagram to a new designer or team to work on. Ideally, I’ll give the new design to people who haven’t worked on any of the components to encourage the cross-pollination of ideas and get us out of the rut of a specific style.

Even when doing so much remote work these days, I still use the same basic method, but over Skype, using digital tools to crop, copy, paste, box, and scribble over whatever the team submits.

This approach works great, gets everyone involved in the actual work, and ensures detailed design oversight instead of requiring a boring presentation of a design to the team to get theoretical feedback.

Adaptive Box Diagramming

I’ve left out one important thing to consider before you start: is the model to scale?

When first starting on a project, I’ll use these methods without a bounding box. On a whiteboard or other drawing surface, I’ll just lay out the boxes wherever they go. You can place the content as needed, transparently evolving your understanding of the relationships between the elements.

However, these diagrams are deliberately not yet exactly representative of the page designs. You are just establishing the relationships between elements. What is most important is what items are next to each other.

As you go deeper into the process—or when making revisions to existing products—start by drawing a box around an area to denote a page. Sometimes, it can be convenient to simply use a sheet of chart paper to define the page boundaries. Plus, you can move a sheet of chart paper around or carry it away with you.

I define what a page is and, ideally, create layouts for several viewport sizes, actually drawing them right next to each other. Information is rarely tied to a single set of pixel dimensions.

As for the final user-interface design, you should not create a box diagram to a specific scale, but only a class of device. Define what is critical—relative positions, relative sizes, spaces, and what is adjacent or not adjacent to each other. Over time, you may evolve this rendering, clearly specifying how the elements move, appear, or change at each breakpoint, or for each device class. Figure 7 shows an example of same page template for two device classes.

Diagramming Templates, Not Pages

Even as I move to more detailed box diagrams, I rarely use the same template for every page in a product that I am designing. Ideally, I don’t need to design every page because the templates, components, and cooperation with the rest of the product team mean we can build pages systematically and programmatically.

It’s critical to understand that it’s best to use this method when you’re considering doing or want to reinforce the practice of

• component-based design
• consistency in interfaces and interactions
• making it easier to follow basic rules—such as the 1, 2, 3 placement I’ve discussed in a previous column

Template design is intrinsically different from page design. It cannot be pixel perfect, but must be rules based. It involves conditionality, modularity, and fluidity. These must be explained or specified, not just drawn. Most people get this once it’s explained to them, but fluid or flexible design is one of the harder concepts, so let’s expand on this.

I never specify the widths of page components using any fixed system such as pixels. While margins and padding do get hard dimensions, areas between the margins are in percentages or have conditions. For example, a table is 100% of the available width and the first column is wide enough to display a date in full, but all others are a uniform width. Thus, a design works at any viewport width. Responsive changes or different adaptive templates are fine on top of this, but between breakpoints, the user interface is a perfect fit, in design and code.

Vertical fluidity is also important. What happens if there’s more text? Does your two-column layout get messed up by a very tall right column that leaves a lot of whitespace in the left column? If so, you may need to reconsider the whole design to avoid that being an issue.

What about infinite scroll? As I discussed in my last column, a key solution is to create floating headers and footers. But designing templates and considering the full range of ways in which the data could display led me to understand that this might be an issue and propose a solution before ever seeing the problem in a coded user interface.

Closing the Loop

Often, when I bring a new or additional step into the design process, I get a lot of pushback on how designers’ old-school, slow, nonagile methods are always holding up the train. While I have many objections to the whole idea of diminishing design time, in case you get that sort of pushback, let me tell you more about how information-design methods help streamline the rest of your process.

First, information design is another solid link between the defined requirements and their execution. Working off good requirements and measuring your results helps close the loop and proves that you are responsive to the project team, user feedback, and other data sources.

Second, information design can help eliminate almost all UI-design work—as long as you have some sort of design system. I always do—even if for only one project. The concept phase always includes creating a style guide and reusable components. The boxes for pages or templates then simply become placeholders for the default text, list, table, or form. If your design work is well integrated with that of the front-end development team, you can go so far as letting them create a first cut of the final user interface without any detailed drawings or comps of individual pages at all.

Lastly, information design—and box diagramming specifically—can be very easy for nondesigners to understand. The diagramming process lets you involve everyone with parts of the design, helps get the team to buy into the design process, and possibly even avoids their nitpicking about the user interface later on—because they’ve become invested in the higher-level design choices. 

Resources

Gable, Gene. “Scanning Around with Gene: Throwing Away the Pasteup Books.”Creative Pro, September 14, 2012. Retrieved December 18, 2018.

Hoober, Steven. “Paging, Scrolling, and Infinite Scroll.” UXmatters, November 15, 2018. Retrieved December 18, 2018.

Hoober, Steven. “Mobile UX Design Approaches: Workshops.” UXmatters, September 8, 2016. Retrieved December 18, 2018.

Hoober, Steven. “Design for Fingers, Touch and People, Part 3.” UXmatters, July 10, 2017. Retrieved December 18, 2018.

Jacobson, Robert. Information Design. Cambridge, MA: The MIT Press, 2000.

Kononenko, Kevin. “The CSS Box Model Explained by Living in a Boring Suburban Neighborhood.” Free Code Camp, March 26, 2017. December 18, 2018.

Spool, Jared M. “The KJ-Technique: A Group Process for Establishing Priorities.” UIE, May 11, 2004. Retrieved August 23, 2016.