Adding Grid Focus to a group sketching activity is, in my opinion, a great example of how a small additional effort early in the development of a design idea can have a large beneficial impact over time.
What is Grid-Focused Sketching?
Grid Focus, in the context of sketching, is simply to ensure that the page grid and layout is actively discussed as part of a group ideation activity. Too often, while the sketches team members produce may imply a certain layout, the choice of layout is rarely explicitly discussed, and is instead something left to the visual designer to figure out on their own at a later point.
This is a big mistake in my opinion. And the mistake is tied to an archaic print-world notion that the page grid is the domain of the visual designer. The reality, of course, is that the choice of page layout can have a significant impact on user experience and that, in contrast to print, layout in the digital domain has a dynamic potential that many visual designers may not be considering.
For this reason, engaging the entire team, particularly UX and Tech leads, in defining the grid at the sketching stage can make for a better design solution, mitigate possible aggravation and headaches down the road, as well as allow for an overall more efficient design process.
So how does Grid Focus work?
Obviously, that will depend on the idiosyncrasies of your team’s process, but here is one possible example:
Imagine your team is in front of the whiteboard, various team members drawing and commenting on one anothers ideas. Once a design idea has begun to take shape, you shift your discussion to page layout. These are some possible questions you might discuss as part of a grid focus.
Is there a legacy layout?
If you are redesigning an existing application, there is commonly an urge to discard the old layout and replace it with something new. Switching to a new layout, particularly for legacy users, can be quite risky, since they’ve learned to expect that certain types of features and information are located in certain parts of the page. That is not to say that one shouldn’t explore new layouts, rather that the team as a whole should be aware of the potential risks, so that the visual designer doesn’t go off and create a completely new layout without considering legacy issues.
Should we go with a standard or custom layout?
Though it may not be apparent to non-designers, most web pages are designed using one of a small number of standard layouts, generally either a two-column or three-column layout.
Therefore, a standard/custom layout cost-benefit discussion should happen early on, rather than allow the visual designer to spend time creating a fancy custom layout, only to then learn that it will be a major headache to build. Of course, if you are designing a highly brand-intensive site (e.g. a fashion site), there might be a strong business case to be made for investing time in a custom layout, but it should still be explicitly discussed early on.
What will be the roles of various page regions?
As we are sketching out ideas, we often draw boxes representing various parts of the screen. What we don’t do often enough, in my experience, is to discuss the larger role of a given page region within the overall application context. For example, in a 3-column layout, do we want to use the 3rd column for contextual help information related to the 2nd column, which will contain the primary page content? Discussing page regions in terms of these roles can facilitate creating a more consistent experience across the entire application, with the same type of information consistently appearing in the same region.
How does this layout work relative to that of the referring page?
Something easily forgotten when working on the design of an individual template is that the page is part of a larger flow. In other words, the user will in most cases be arriving at this page from another page in the application, for which reason it is critical to be looking at the relationship between this page’s grid relative to that of the referring page. When moving between application pages, one ideally only wants the page region relevant to the current flow to change, since it is the part that shifts on the page that will draw the user’s eye. In other words, let’s say we are working on designing a product detail template. In doing so, we also want to be looking at it in terms of the transition to that page from the page likely to precede it in a user flow, such as a products listing page. If those two pages are designed using significantly different grids, and the same information appears in different locations on the two templates, that is certain to disorient users. Just as filmmakers talk about everything being ‘in the cut,’ so too is how pages are juxtaposed a critical factor in user experience.
Do we want the layout to respond to user behavior, window size, medium, or user agent?
In contrast to print, in which there is one and only one grid per page, a single page in the digital domain can be highly dynamic, i.e. the grid can change depending on any number of factors, such as what type of user agent (e.g. Firefox or Internet Explorer) is being used, the size of the browser window, the output medium (screen, print, projection), or some user behavior. One major reason, I think, why so many pages are designed using only one static unchanging layout regardless of these factors is because it has been created with a print-world mentality. But by opening up the grid discussion during sketching, we great a much better opportunity for taking advantage of the range of dynamic grid choices.
For example, let’s say we have a 3 column grid for the default web view, but maybe it makes more sense to go with a 1-column grid for print, in which we maybe remove the first column altogether (let’s say the first column only contains navigation) and float the 3rd column to be down below the 2nd column, which would make sense from a linear reading perspective, particularly if the 3rd column contains additional reference or help information related to but secondary to the main content in the 2nd column.
This type of broader thinking relating to the page grid is, in my experience, much easier to accomplish as a team, allowing us to consider and design for the range of ways in which users might experience our product.