Strategy Blog: Viget Labs

Kevin Vigneault - User Experience Designer :

One of the things that slightly bugs me about Omnigraffle is that it doesn't have built-in objects for basic HTML form elements that behave like real ones. I would love to have these to add a little more realism to my wireframes and possibly extend them to work inside of a more full-on prototype with "real" forms. So, I recently took a shot at creating some clickable form elements for myself using a combination of Applescript and the custom data feature.

Warning: What I hacked together works, but its not foolproof. I've included some notes below that should help you in using this stencil.

Download the Stencil (Viget.FormElements.gstencil, 156 K)

Checkboxes

• These can be clicked on to toggle between checked and unchecked states.
• The label is stored as "value" within the object's data.
• The state (checked or unchecked) is stored in the object's data and can be keyed off of for further prototyping.

Radio Buttons

• These can be clicked to change the selection in a group of radio buttons.
• The label is stored as "value" within the object's data.
The state (selected or unselected) is stored within each object's data and can be keyed off of for further prototyping.
• They are grouped together as a table, so it's easy to add new rows or columns of radio buttons.
• The unselected radio image is a separate object that needs to live behind the table and can't be grouped with the radio buttons (sorry, it'll break the script).
• To create multiple groups of radio button on the same canvas, you'll need to give each group a unique name. The table has a data item "groupName" currently set to "Fruits". Each object in the table has a data item "group" - also currently set to "Fruits". Both of these need to be changed when another radio group is created.

Drop Downs

• The option that will be displayed when the dropdown is collapsed is stored as "defaultOption" within the object's data. When it's expanded, "allOptions" will be displayed.
• A lot of the styling is contained within the script, so if you want to tweak the styling, I would suggest looking at the script to see how styles are being applied.
• The value that is selected is not passed back to the parent object, so this element is not set up for further prototyping. It is good for showing the list of drop down options without using another layer.

I've also included some buttons and text fields in the stencil. I'm sure there are improvements that can be made to these, so everyone should feel free to use and modify this stencil. If anyone creates something better (especially a dropdown that fully "works"), I'd love to hear about it.

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"

Todd Moy - Senior User Experience Designer :

 

Over the past four months, I've been using Omnigraffle as my go-to diagramming app. During that time, I've collected a small set of tricks that make wireframing and diagramming easier.

If you're a grizzled 'graffle veteran or someone who reads manuals, some of these might be old hat. But maybe not – so check them out.

 

Continue reading "10 Omnigraffle tips you might not know (plus one bonus!)"