in Process

Adding Grid Focus to Sketching

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.

Choosing one of these layouts is likely to both be more cost-effective in terms of implementation, i.e. a front-end developer will be able to much more quickly create a three-column layout, compared to something more customized, and also less risky in terms of user experience, since information is organized in a way that users are more likely to recognize.

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.

  1. Plausible approach in general. Agree with Anders: How it is being executed in a team, largely depends on the team, or even the type of agency structure you have. When you work in a setting where you have distinct UX and visual design teams, in the eyes of visual designers, the UX lead tends to be somewhat responsible for the “layout”. In some projects this might be necessary, in other not at all. However, the term “layout” is somewhat anachronistic because it connotes a finality that just isn’t there. Effective UX lead-Visual Design Lead collaboration shouldn’t be predicated on deliverables but more on roles of their subject matter expertise. A visual designer should weigh in on the UX leads wireframing process as should the UX weigh in on visual design questions. When you are responsible for leading an integrated team, you have to ensure that people don’t fight for a lead role over the deliverable, but rather cultivate an atmosphere of collective best thinking.

  2. Hi Fritz,

    In my experience, who leads the session depends somewhat on the team and project. Usually, it’s led by the UX Lead (which really could be the same role as creative lead for some teams), though sometimes a product manager might lead. And yes, breaking into micro-groups definitely makes sense. One way to do that is to take an approach similar to the Pair Design model I propose in the following post.

  3. Hey Anders, love this approach and it is totally plausible.

    Question as I didn’t see it explicitly mentioned, but do you see this session at least being lead by a creative lead (who may or may not be the visual designer)? Also I see value in breaking out into a microgroups (IA +VD) to broad stroke ideas and then present it for a group crit to dissect as per your above comments. Thoughts?
    An agile implementation of your suggestions could even possibly include each thought area be taken as a separate iterative cycle (occurring a few times within a given week).

    The reason I ask the above is that I’ve seen quite a bit proposed but in practice go a bit awry on the implementation side. Comments welcome. Good stuff all around though. – F

  4. In my experience, I’ve simply introduced it by raising the above questions once a general design direction has begun to take shape. (In the capacity of the person leading ideation sessions.)

    For example, once someone has presented an idea that it seems the team feels is strong, I might point out that the layout in their sketch is radically different from that of the legacy application and ask them to make a case for why the layout should change. Or if the layout appears to be completely non-standard, I might ask the developer to talk about how costly/complex it would be to implement. Or I might refer back to some research data that shows that the current user base has a wide range of monitor resolutions, and do we want to optimize for different layouts?

    Fundamentally, I’ve found it to be less about education and more about team awareness that the grid is not something the visual designer should work on in isolation.

  5. Hey Anders! I like your notes on grid focus. How would you introduce it, in a team setting, grid issues like you pointed out when not all are aware or savvy enough about these aspects? Any suggestions short of some pre-education?

Comments are closed.