Strategy Blog: Viget Labs

Todd Moy - Senior User Experience Designer :

Divide-the-Dollar is one of my favorite elicitation techniques. If you're not familiar, this technique is used to understand what people value – and in what proportion. Participants in the exercise divide a pool of money (or poker chips, sometimes) among a set of options, making judgments and trade-offs.

The Problem

I don't use Divide-the-Dollar as much as I could. Why?

First and most critically, there are very few online tools that can be used to orchestrate the exercise. Many of our clients and their customers are remote, so we tend to rely on online apps when we can. The main online app that is designed for this purpose – MindCanvas – is expensive and possibly unsupported. While it's possible to build a spreadsheet to manage the logic and capture the data, the experience is rough at best when working with end users.

Second, running onsite tests with a human moderator is expensive and incurs a lot of overhead. Scheduling, dealing with no-shows, and conducting the exercise all eat into budget and schedule. It doesn't scale well and discourages quick, guerrilla-style studies. 

So the problem is technical: the tools aren't there. But on my commute in to work, I realized there was a way to do this if I thought about the problem differently. 

Continue reading "Running Online Divide-the-Dollar Studies using WebSort"

Laura Sweltz - User Experience Designer :

Due to time constraints on a recent project, we decided to skip the formal wireframe process and go from sketching right into design.  We found the process to be quite successful, thanks in large part to the fact that we were working with a savvy client that was willing to actively participate in collaborative sketching.

After a successful kickoff meeting with the client where we gained an understanding of the goals, aims, and content for the site, I took the information that we had gathered, thought about the overall structure of the site, and did some preliminary sketching on my own.  With a site map and some general ideas in mind, I was ready to meet with the client again for our collaborative sketching session.  We reviewed the site map to make sure that it met their needs, completed an exercise to define the unique aspects of various content types, and then I led the main sketching exercise.  We spent half a day working collaboratively to sketch out the various pages together and then later that afternoon, I refined the sketches on my own and posted them for the client to review.  They gave us the go-ahead and design work began.  Since we were collaborating directly with the client, we were able to gather the necessary information, come up with a solution, and get approval from the client in a very short amount of time.

Here are some key points to making a process like this successful:

• Make sure the client understands the process and is willing to participate in collaboration.  This type of process can only be successful if you are working with a client that is comfortable with real-time collaboration and is willing to participate.

• Bring together the right group of people.  Make sure that the key decision makers are in the room.  Also, only include individuals that will be willing to participate.  Any potential blockers should be left out of the session.

• Include the designer in the sketching session.  Including the visual designer in the sketching process is vital.  If they are around when the decisions are made, you won't have to spend an extensive amount of time walking them through the sketches.

• Set realistic expectations for the meeting.  Make sure that all attendees know what needs to be accomplished in the given amount of time.  For example, noting that the group needs to get through pages A, B & C and if there is additional time, that pages D & E can be addressed as well will set realistic expectations and help keep everyone on track.

• Come ready with ideas to jump off the conversation.  Come prepared with ideas to use as jumping off points to get everyone's creative juices flowing.  For example, quickly sketch some very basic options for a page and say "Which path do we want to go down?" and then the group can work on coming up with a fleshed-out version of that page together.

Although this process won't work for all projects, it turned out to be a very successful approach for this one.  If there's a project where it might work for you, I suggest giving it a try!

Todd Moy - Senior User Experience Designer :

"That should have been brought up when we looked at wireframes"

Whenever I hear remarks like this, I usually feel it's not the client's comprehension that's at fault – but how the materials were presented. As UXDs, our job is to communicate and if the message isn't coming across, then that's our problem.  And let's face it: most people never come across a wireframe or any of our other arcane documents. There's a learning curve that we need to manage.

Launching right from a cover slide into the grit of wireframes will rarely go as well as expected. As we flip through the screens and point out this and that, clients are trying to provide intelligent feedback while grasping blindly for context.

Below are three visual tactics I've used to help smooth this process and get good feedback. These aren't a replacement for honing your presentation skills, but they can be good accompaniments.

Tactic 1: Tell a Story

Maybe it's me, but it feels unnatural to critique a design outside the context of a user's goal. So, it makes sense to use a storytelling approach to present them.

I like to frame a set of screens in the context of a scenario. These state the motivation for the action, the conditions present, and the desired goal.

Given this scene to turn over in their head, I find people can better evaluate the wireframes since they can role play through the interaction. Typically, less time is spent debating subjective details and more time is spent discussing how well it accomplishes a goal. As a secondary benefit, you can reuse the personas and scenarios you developed earlier, demonstrating how that work influenced this.

Visually, I use a flow diagram that uses screen thumbnails instead of generic boxes. The "small multiples" help tease out the state changes within an interaction. When hyperlinked to the corresponding wireframes, the flow becomes a visual table of contents. 

Continue reading "3 Tactics for Improving Wireframe Presentations"

Kevin Vigneault - User Experience Designer :

Omnigraffle has become my hammer for creating a variety of things. I use it for wireframes, sitemaps, concept models, charts, reports - pretty much whenever I need to create a document. So, while there are a number of other great prototyping tools like Axure, Protoshare, and plain old HTML, I look to Omnigraffle first when I need a simple, clickable prototype. Here's a quick overview of how to do that.

Adding Actions to Objects is Simple

Just select an object and pull up the Inspect window. Within the Properties section, select the third option, labeled Actions.

By default, all objects are set to "Do Nothing". To make an object do something on click, change this selection to one of three actions; "Opens a URL", "Jumps Elsewhere", or "Shows or Hides Layers". There are two others, but I have not found a use for "Opens a File" yet and "Runs a Script" is too fancy for me. I should also note that "on click" is the only trigger Omnigraffle can handle. If you need to mock up hover actions or data entry, you probably need another tool.

• Opens a URL - Use this to link to external websites. For example, you may wish to link a Tweet button to Twitter.com.
• Jumps Elsewhere - Use this to link to other canvases in your Omnigraffle doc. Personally, I like to keep canvases in Omnigraffle analogous to pages on a website, so I try to only use this action when linking to unique pages. It's also nice to use this to link form submit buttons to the page users should be redirected to when the form is submitted.
• Shows or Hides Layers - I'm a big fan of this action for mocking up interactions within a page. A good example of when to use it is if you want a modal window to appear when the user clicks a button. To do this, create a new layer of your canvas called "Modal Window" and set it to hidden. Then set the action on the button to show the modal window layer. For a final touch, create a close button and set its action to hide the modal window layer. Using "Show or Hides Layer" for these types of interactions keeps the number of canvases you have to manage from getting out of hand.

Using Your Prototype

• In Omnigraffle - The quickest way to try out your new prototype is to just use Omnigraffle. To interact with the actions you've created, either hold down "B" on your keyboard or turn on the Browse tool. You'll then notice that hovering over objects with associated actions causes a pulsating blue outline to appear. Clicking on the object will then execute the action. For better presentation, it helps to select "Hide Toolbar" from the View menu. A big drawback to testing out your prototypes in Omnigraffle is that standard browser actions, specifically back, are not present.
• Outside of Omnigraffle - If you want to share your prototype with others who don't have Omnigraffle, you'll need to export it. You can do this as either a PDF or as HTML. I prefer HTML because the person testing the prototype will experience it within a regular browser. This helps both because it simulate the look and feel of a web experience and because most of the standard browser actions are supported. The biggest drawback however of using either export option is that they do not support the "Shows or Hides Layers" action. If you're going to export your prototype, you'll need to stick to linking between canvases and to external URLs.

If you have any tips, comments, or questions about making Omnigraffle prototypes, please leave some comments. I'd be happy to discuss.

Todd Moy - Senior User Experience Designer :



Here's a pretty typical site map: boxes and arrows, a decision point, and a conditional section. If you're the person who diagrammed it, you already have a good sense about how the system will work. You know the major interaction paths and what type of content will be present. You know the purpose for each of those pages. 

Yet those generic little boxes betray that knowledge. To those who weren't part of the creation process, it takes a leap of faith (and a lot of questions usually) to really understand what is occurring. These boxes don't communicate the context of the interaction. The intent and purpose of each page is a bit nebulous. 

Page archetypes help you better express what's going on in your site maps and user flows. 

Continue reading "Improve your site maps with page archetypes"