The Challenge

The bulk of our effort was spent designing a user interface for media features at the top of the page as well as structuring descriptive content about a product category and it’s ongoing targeted campaigns.  These campaigns - covering a wide range of topic types - necessitated a migration of content from disparate and floating pages throughout the page architecture into this more unified and simple page design.

As we moved through initial design iterations, our team had successfully made the case for reduced but more powerful content, and the media player UI was holding up quite well.  However, skepticism began to emerge on two fronts: (a) what kind of video storytelling are we going to actually do, and (b) can we accomplish all of our goals amid such content reduction? The dissenting voices came not just from stakeholders and design team leaders, but also a new voice in the organization: content strategists whose influence was welcome but not exactly well defined…yet.

The Solution

As these concerns arose and usability testing approached fast, our efforts immediately pivoted to assessing the impact of content strategy and migration via a prototype.  Information architects had used a pre-existing documentation system to produce numerous wireframes based on formalized templates and components (reusable page chunks).  A quick discussion between the IAs and their audience for this prototyping session - the content strategists - yielded interest and confidence that the wireframes could be extended by the strategists themselves.  While not familiar with advanced design tools (in this case, Adobe InDesign), content strategists were motivated to “draw” an experience in a real-life simulation of a copywriting and publishing exercise using these wireframes.

Step 1: IAs genercized wireframe templates of the design solution, and passed those templates onto the content strategists that would use the same design tool to “publish” their content.
Step 2: The content team performed an actual if accelerated content migration and authoring cycle using the  templates, resulting in over 20 pages of production-quality content rendered as wireframes.
Step 3: The IAs and content team worked together to aggregate the wireframes into a clickable deliverable PDF.
Step 4: The prototype was presented to project stakeholders and resulted in critical feedback leading up to usability testing.

Results

The prototype enabled the group to improve the page and component-level design, assess content migration (particularly, all that content that was to be dropped), and determine if the project’s design goals had been fulfilled.  It was also a reality check to see if the proposed video content “felt right” and addressed coherant topics amid the larger page design, even if video was represented as static images with feature titles and descriptions. Video content of high production value is not cheap, and it wasn’t possible to produce any BEFORE the video player design was complete, so we faked a toggle across multiple video features.

Shockingly, even as the content team discarded 80% of the content while migrating it into the prototype, the team actually ended up removing an additional 50% of what remained during the prototype reivew.  IAs and content strategists now had a platform for collaboration, and discovered a better solution.  The project team was left with a prototype reusable in two ways: a demo to share with their executive sponsors AND sufficient artifact - with real content! - to use in usability testing.

Just as importantly, the prototype enabled stakeholders and copywriters to transcend the design discussion and get a sense for how the design would work as if already implemented.  The two parties worked tightly to migrate and polish content amid deadlines, competing interests, and a solution that challenged the status quo of content delivery.  Thus, instead of being left with an implemented & inflexible design, the two groups  identified issues long before lock down to shape a solution they could comfortably live with.

Next Steps

Leading up to usability testing, the team was far more confident about the state of the prototype - and the design.  Much if not all of the trepidation around adopting a media-rich solution had subsided, and the group had reached consensus on what, why, and how content was going to be vastly simplified.

Irregardless of the testing outcomes, IAs were now far better equipped to write specifications and editorial guidelines for publishers based on the interaction and feedback from content strategists.  Even better, IAs and content teams were also discussing enhanced techniques for co-producing design artifacts, such as creating wireframes in Adobe InDesign while authoring copy in Adobe InCopy files dynamically linked to the wireframes.

Lessons Learned

Content strategists yearned to exercise their emerging voice, while information architects were tentative to “let go” of total ownership over what had been their deliverable.  However, the two groups combined in a mutual mission, and delivered a useful and revealing artifact.  In the end, mutual trust and shared collaboration prevailed, the design was improved, and enhanced processes emerged all within the context of a prototyped solution.

For that picture, I’ve come up with a table of options with pros and cons, and would love your feedback!

Information Architecture Summit
March 19-21 in Memphis, TN

For the first time in my career, I’ll be facilitating a pre-conference workshop at the IA Summit! I’m very excited, and look forward to some great brainstorming, conversation, and excitement as we cut up more screenshots and consider the potential of pattern and component libraries for our own sites. This seminar will define the role of components and why they matter, map out how to organize and build a library, describe how to use components in practice, establish a process for documenting and maintaining components, and much more. To register for the pre-conference and find out more about the IA Summit, visit http://www.iasummit.org/2009/.

Web App Summit
April 19-22 in Newport Beach CA

I’m excited to be presenting a full-day seminar on Achieving Reuse with Patterns and Components at UIE’s Web App Summit on Tuesday, April 21. This summit is 100% dedicated to web applications and, in my humble opinion, is one of the best conferences out there. Check it out at http://cli.gs/2Rj35R. Use CURTIS as the promo code when you register, and you’ll get $50 off a day. Register for all 4 days, and you’ll get a free iPod nano too.

Book Discounts for Workshop Registrants

For attendees of either workshop, I’ll provide an additional promotion code to purchase my upcoming book, Modular Web Design, directly from Peachpit Press. In addition, you’ll get free shipping too!

Admittedly, InDesign’s learning curve for getting started exceeds most if not all other popular design tools. But with that investment to learn the tool comes a power to modularly create and collaborate on design solutions and documentation.

Usually, the choice of InDesign over Visio (or Fireworks or Illustrator or Omnigraffle) for a wireframing system boils down to points like:

• InDesign is cross platform (Windows & Mac). If you want everyone to play, including vendors with unpredictable platforms and/or a nagging disdain for Windows, then Visio AND Omnigraffle are quickly dismissed.
• InDesign is by far the most modular, with snippets, object libraries, and capabilities to dynamically link files to one another. Visio is on the other end of the scale, with but the use of stencils in narrow ways to control instances within a single document. Visio documents are where screen visualizations (in this case, wireframes) are embedded with no opportunity to reuse within (such as a wireflow) or across (such as multiple deliverables per project) documents.
• InDesign’s  style power (rather, distinct style types for paragraphs, characters, objects, tables, table cells) includes such a deep array of customization, inheritance, and typographic control that vastly exceeds any other tool for creating wireframes and managing a system based on a formed, mature visual system. Sure, it’s wireframes, and they aren’t meant to be pixel perfect. However, systematic wireframes should reflect the established visual conventions of structure and behavior that typography and basic object styles can imply.
• InDesign is for creating annotated documents. While both Visio and Omnigraffle also support a page model for publication, Illustrator and Fireworks are solely dedicated to creating screen visualizations, not associated annotations that can be detailed, versioned, and so on. Additionally, InDesign’s embedded features for document variables, rapid TOC creation, and application of standard layouts enables designers to more rapidly produce more polished documents.
• InDesign supports more powerful grids, vector-based drawing tools, and layer organization than non-Adobe Creative Suite products, with a similar goal to that of typography: implying the standard visual conventions for laying out different page chunks.
• InDesign empowers collaboration across resources not limited to UI/Information Architects/Interaction Designers, but also content strategists (via threading InCopy with InDesign), visual designers (with InDesign’s fully featured placement and control of Photoshop layers and layer comps), and others. InDesign is a publishing platform built on collaboration. Visio and Omnigraffle are made for a single person to own and publish a document in isolation.

The big theme is that InDesign provides the only software tool on the market today by which you can unify delivery of user experience documentation across a range of disciplines. The result? Increased collaboration between designers, governance across designers, and credibility of the design organization outwardly to other groups. Otherwise, it’s every designer for themselves.

The following video demonstrates how to setup styles so that all the wireframer need do is apply a style, type in the header text, hit return twice, and the frame then has a nice horizontal rule separating the header from content and the cursor is at the ready for more normal formatted content to boot!

The solution? Start with an object style (for the “frame” object) that includes a paragraph style starting point (for the first line of the frame, in this case, the “frame header” paragraph style). Then, set up the “Next Style” of each paragraph style to point to the next line; that is, the next style after “frame header” is “frame horizontal rule”, and the next style after “frame horizontal rule” is “normal paragraph.” With that style sequence, creating the most common display (or starting point) is done in a jiffy!

Information architects devote much time and care producing annotated wireframes. In large part, this boils down to positioning pictures (i.e., a wireframe) adjacent to words (i.e., the annotations) to tell a story that neither could tell completely without the other. Annotations commonly describe behaviors, states, content, and other properties of a wireframe page or component, and generally the two are mapped together via call outs (lines connecting the pictures and words) or markers (number or letter references placed on top of the picture).

Over the last two years as a part of over 15 documentation system engagements, I’ve reviewed over 1,000 deliverable documents produced by over 100 user experience professionals. Over 70% of the documents were produced by information architects or interaction designers, and over 50% of their documents were some form of annotated wireframes. To be clear, I’ve seen A LOT of annotated wireframes from many different people.

So, how does everyone layout a combination of wireframes and annotations? There were a few samples that positioned wireframes above the annotations, and the layout seemed fresh and inventive only because it was so rare and broke a predictable pattern. What pattern? The overwhelming majority positioned wireframes and annotations side by side.

Why side by side?

Generally, due to the variable height of both wireframes (generally, in some sort of rectangular shape) AND annotations (generally one or more vertical columns of flowed text).

Put one on top of the other, and you can’t predict page-to-page where to find the one on the bottom.  If there’s even room on the page given the height of the other.

Plus, imagine viewing the page in Acrobat (most deliverables are published as PDFs). Depending on how the document opens and other factors, the piece on the bottom may be below the visible portion of the page.

I also suspect, although I reference no scientific basis, that humans are more adept at shifting their vision from left to right and back again than bouncing up and down. That is, they can map and compare wireframes and annotations better when side by side rather than stacked. Survival instinct to scan the horizon, perhaps? I digress.

Which appears on the left more often?

Overwhelmingly, the wireframe picture is placed on the left, and then annotated on the right.
Despite the best efforts of one team — who otherwise used highly structured templates and had mature wireframing technique — to persist a template with annotations on the left, there were even rogue examples within documents that shifted annotations on the right. It was as if someone started from scratch 50% of the way through, and the remaining pages flip flopped the display.

Beyond that unexpectedly erratic layout, every other team that submitted more than 3 to 4 annotated wireframe documents put the annotations on the left, in every sample.

Why put the wireframe on the left?

Priority: It doesn’t matter how tight, scannable, and usable our annotations are. Consumers look at the wireframe before the annotation, always, no matter what. So put the picture on the left so they can read — as they’ve always be trained to — from left to right across the page.

Timing: I can’t think of an instance where I started writing annotations without having at least an initial version of the wireframe to annotate. Often, I’ll create and publish a document with only the wireframe, without annotation. Wouldn’t it look odd to put the wireframe on the right, have no content on the left, but most likely retain the page title (and potentially other document information) in the customary upper left? What if you started with the wireframe on the left, but once you start adding annotation, moved the wireframe to the right? Hogwash.

Appearance: By placing a nearly always rectangular wireframe shape (usually enclosed in some type of overall frame) to the left of left justified annotations, you achieve a sharper, more structured, and connected layout. That’s in contrast with a ragged right display of left-justified annotation text to the left of a wireframe’s frame, resulting in a unpredictable negative whitespace that is visually unattractive.

“Dude, why are you asking this question? You need to get out more.”

Earlier today, I finished facilitating a grueling but rewarding 1.5 day training session by presenting the best deliverable I’d ever produced. It was glorious, highlighting layers of modular wireframe reuse, detailed but usable specs, and rich stories of workflow and creativity. It was inspiring, leaving attendees encouraged to research, “usability test,” and ultimately deliver documents designed best for those who will consume them. It was as if I concluded with a rousing “go get ‘em!”

But the document was ~3 years old, and barely preceded my creating a more formal system of templates & techniques for UX deliverables that, among other things, assumes wireframes go on the left. So many good principles were evident in my sample I shared, and the document was nearly visually indistinguishable from the system. But I noticed 2/3 the way through, in a “Huh?” moment, that all my wireframes were on the right. It stopped me cold.

Did the document fail? No way. But I knew right then, even the best deliverable ever made — by the pontificating “expert,” no less — could have been better. And that was the best lesson I taught that entire session.

The options are:

• As-Is: The production site reflects the current state of the experience, including all the concessions and trade-offs made to get launched. As such, it may not be an optimized design and may not be exactly how design would be built in the future.
• As-Intended: Even though trade-offs were made during the design process, a design team may still have design artwork and requirements reflecting a preferred, optimal experience.
• To-Be: While a site may already be in production, there’s either already emerging new designs launching soon or planning underway to redesign a considerable portion of the existing experience.

Deciding on what kind of library you should build out can be a tough balancing act, one that may even blend more than one of the above options. How do you decide? Generally, think about your library objectives and fully understand what “reuse” of these components really means.

Will designers, publishers, and others continue to update existing and create new pages that employ as-is suboptimal components unchanged? Then it makes sense to catalog and publish as-is components.

Will your group be launching updates to the experience to move towards as-intended components? Then include those in your library.  If not, then our best intentions may not be useful to other resources working within the reality — and constraints — of an implemented system.

Will a new site design that includes a range of to-be components be launching soon, but other team members cannot utilize the new components until 6 months later when the site is live? Then refrain from adding those items to your library until it makes sense for others to benefit from them.

Thoughts?

So, alright, this might not be the BEST idea I’ve ever had.  However, it’s worth a post.

I’m asked frequently why we go with a letter landscape orientation for our default deliverable document.  The primary objection centers around a limited height for wireframes / mockups / screenshots, such that one may often have to resort to the “jagged edge” frame for the artwork.  My initial response is “Well, it’s modular, right?  So you can show the rest of the wireframe on the next page, and this situation doesn’t happen ALL that often, right?”

But then it occurred to me: what if the deliverable page could interactively show segments of that wireframe based on a button collection for pagination?  So, in the matter of 10 minutes or so I roughed out a “Click to view page segment” button set along with three frames for the artwork so that you can easily page up/page down through the full artwork within a single deliverable page. The solution is depicted in the short video below (<3 min).

(don’t forget to view full screen for best results!)

A state is a condition or mode of being, where the user interface or system satisfies particular conditions and/or awaits an interaction. Under different settings, the UI will produce perceivably different display variations or results. When annotating an interaction design, it’s helpful to comprehensive describe the range of states of each page, component, or even element of an experience. With such visual and textual descriptions, you can concretely set expectations to establish consensus and foster understanding across your documentation’s many audiences.

Common examples where a designer considers states include:

• When to show or hide a messaging unit to invite the user to sign in to a personalized experience.
• When particular tabular components are included above, below, or omitted relative to other components based on stored data
• When explicit user input (such as a product selection) as well as implicit behaviors (navigating an audienced site section) result in data entry defaults in a checkout process

The Fundamental Question

When describing states in interaction design, the designer’s focus is on the user - what can the user see, what are they perceiving, how is their cognitive model mapping to what the system actually manifests? Ultimately, these instances can be described by visible states that a designer can boil down to a fundamental question, with three parts:

When do you see what?

First, the “When.” This aspect focuses on the conditions or circumstances of a state. Here, it’s critical to describe conditions in terms of inexorable statements and visualizations, removing any ambiguity as to when such a state occurs - and doesn’t occur. If a designer can’t accurately describe conditions of when a state applies, then any hope at applying the “See” and “What” is fruitless. Example conditions include:

• Signed in?
• Old enough?
• Content available?
• Consumer or business or government?
  
• Account created?
• Option selected?
• Name defined?
• Playlist nonempty?
• A/B test resulted in showing version A?

All of these questions can be posed as circumstances with an answer that cannot be debated, if formed correctly. Yes, the user’s signed in or no, the user is NOT signed in. The user was defined as born before a specific date or the user is too young (or the system doesn’t know how old the user is).

Next, the “See.” This is pretty simple. When taking the user’s point of a view, describe states of a user interface is about defining whether the system should show or hide an element, component, or even a page as an interaction sequence progresses.

Finally, the “What,” which isn’t that complicated either. Here, the designer is looking to define precisely how the user interface appears. What gets shown, or not shown.

How do you communicate “When do you see what?” Via pictures and words, of course, which will be the subject of the remaining two segments of this topic.

One of the things Dan and I wanted to do with EightShapes is offer training. Sharing our experiences with other user experience professionals is enormously valuable, and contributes to our own education in the field.

I’m therefore really excited to announce that EightShapes is holding its first public workshop on August 8. Dan and I have been part of other programs, but have never hosted an event ourselves. This is a huge step for us, and we hope that the relatively low price-point of the session means that you can join us in this first of many events to come.

So, if you’ve been considering taking my intro documentation course, or wanted to double that up with some more heavy-duty thinking on wireframes, this is a fantastic opportunity.

I hope we see you there!