Agile, OmniGraffle, and Native Mobile Wireframing

By Simon Keatley

Published: November 19, 2012

“The problems that we run into … may be amplified—because we’re dealing with more platforms, devices, interactions, and potentially, the consequent slowing of our workflows.”

Working in an agile studio for Deloitte Digital has its UX challenges. As a Senior UX Designer, I get paid to solve problems for clients. Along the way, I facilitate that process by doing user research, sketching, creating personas, and wireframing. We do both Web and extensive native mobile design work. So, in comparison to agencies that primarily do Web work, the problems that we run into at Deloitte Digital may be amplified—because we’re dealing with more platforms, devices, interactions, and potentially, the consequent slowing of our workflows.

Because of this, I’m always trying to make my wireframing workflow more efficient, so I can spend more time sketching, thinking about problem spaces, and getting my work out to the broader team for review, so I can iterate on my designs—especially when I’m working on multiple platforms at the same time! Boil down all these problems and needs, and you get this: Wireframe fast at the lowest fidelity possible to communicate and elicit usable feedback from stakeholders. This can be a difficult task. But as you read on, you’ll see that I’ve found some ways to create wireframes more efficiently, with some UX process and philosophy sprinkled in.

Sketching

“It would be difficult to overemphasize the importance of sketching ideas early on…. ”Sketching should be your go-to tool anytime you’re discussing or iterating on ideas.

It would be difficult to overemphasize the importance of sketching ideas early on, during wireframing and even afterward. Sketching should be your go-to tool anytime you’re discussing or iterating on ideas. As long as you’re designing something that people will use on a screen, the way you communicate your design should use a visual medium.

Too often, I see UX designers skip sketching and jump into their wireframing tool of choice right away. Some of the justifications I hear are these:

  • “Because I’m so proficient with this tool, I can ideate in the tool and more quickly achieve my goal of delivering wireframes once we solidify our ideas.”
  • “My sketching ability is poor, so I wouldn’t be able to communicate the ideas I’m trying to convey.” (The issue is valid, but the end result isn’t. This means you need more practice at sketching!)
  • “My client wants to look at something more polished than sketches and doesn’t understand my sketches.”

By blasting past sketching, UX designers miss out on the opportunity to

  • rapidly generate ideas without the constraints of a wireframing tool
  • reflect on their understanding of the problem space
  • communicate visually to solve problems
  • share and refine ideas before sinking time into wireframing
  • and most important, boil a problem down to its core

If you’re the kind of person who jumps right into your wireframing tool of choice, you’re not yet convinced that sketching is a necessity—and that needs to change. Jared Spool, Bill Buxton, Peiter Buick, and Dennis Kardy have already made compelling arguments for sketching. Remember, sketching is a skill and requires practice to get better! Once you’ve established sketching as part of your UX workflow, you can move on to wireframing.

Wireframing Is Not a Magical Deliverable

“The goal of wireframing is to communicate an idea quickly. The faster you can create and distribute your wireframes for review, the more time you have to think, sketch, and revise your work.”

Ideation and sketching should never stop, but at some point, you’ll need to share your ideas with another designer or a developer, and wireframes are a good medium for that. The goal of wireframing is to communicate an idea quickly. The faster you can create and distribute your wireframes for review, the more time you have to think, sketch, and revise your work.

Without diving too deeply into either the purpose of wireframes or what the appropriate fidelity is for wireframes, I’ll summarize my philosophy: wireframe with just enough detail to communicate your ideas to your intended audience—and never more than that. With each client, this process should mimic a dance where you show them low fidelity, they come back asking for higher fidelity, then you translate and distill their requests into a revised wireframe. But don’t go higher fidelity just because they ask you to, it’s your job to decide whether that’s appropriate.

Wireframing Tools

You might use Keynote, Visio, Axure, HTML/CSS, Creative Suite, or one of the many Web applications for wireframing—such as Fieldtestapp, Proto.io, or Fluid.ui—and your tool of choice is probably fairly entrenched. Lots of tools are very capable, but if you’re looking for speed, simplicity, and low-to-medium fidelity, there may be a better alternative.

My Choice Is OmniGraffle

“OmniGraffle has made my workflow more efficient. … OmniGraffle provides the fastest approach to wireframing your ideas, at a fidelity level that should keep your clients focused on ideas, not pixels.”

I am a huge fan of OmniGraffle because it best meets my needs and supports my goals. OmniGraffle has made my workflow more efficient. The best way to decide whether OmniGraffle might be right for you would be to use it and nothing else for a sprint or project. You’d need to use stencils and templates to fully benefit from using OmniGraffle, but even without them, you would likely see your workflow speed up. However, if you don’t use stencils and templates with OmniGraffle, you’ll be slowing yourself down unnecessarily.

Almost all tools offer libraries, stencils, and some form of object management, and you’d have to put effort into becoming familiar with these tools. However, with OmniGraffle’s Graffletopia, you’re sure to find something that you can use to save yourself time when wireframing. Even Google makes their Android design widgets available for OmniGraffle!

OmniGraffle provides the fastest approach to wireframing your ideas, at a fidelity level that should keep your clients focused on ideas, not pixels.

Managing Wireframe Fidelity

“When you’re wireframing at low or medium fidelity, … OmniGraffle shines. It isn’t built to represent pixel-perfect designs. … OmniGraffle has kept me from focusing on pixels too much….”

When you’re wireframing at low or medium fidelity, as shown in Figure 1, OmniGraffle shines. It isn’t built to represent pixel-perfect designs. I see its lack of features that other, more powerful applications offer as a strength. There’s less clutter to slow me down. More important, OmniGraffle has kept me from focusing on pixels too much. This is a benefit even though I’m prototyping native applications for mobile devices, on which real estate is at a premium.

For example, if early during your ideation process, you show clients or stakeholders highly polished wireframes with colors, company branding, and typography, chances are they might get hung up on fine details rather than focusing on the big picture—for example, mental models or affordances on which you’re trying to get feedback. Even grayscale wireframes can be so pixel perfect that stakeholders miss your concepts and focus on granular details instead. So create a low-fidelity stencil and save yourself a lot of headaches. I suggest you avoid the sketchy stencil fad, too.

Figure 1—A grayscale, medium-fidelity wireframe

A grayscale, medium-fidelity wireframe

Stencils

“My top reason for choosing OmniGraffle is its great flexibility in terms of the available stencils and how fast they make wireframing. … You just group objects together and save them as a stencil.”

My top reason for choosing OmniGraffle is its great flexibility in terms of the available stencils and how fast they make wireframing. While the stencil concept is familiar, various tools do stencils in many different ways. OmniGraffle handles stencils fairly simply: you just group objects together and save them as a stencil. That’s it.

The strongest part of how OmniGraffle does stencils is the way it handles viewing them, as shown in Figure 2. You can get an overview of a stencil from a 10,000-foot view or focus on individual objects. Thumbnails actually scale based on the size of an object, and you can drag and drop objects onto a wireframe. Contrast this approach with Creative Suite libraries, in which thumbnails don’t scale and there is no high-level view. With Graffletopia’s strong community and its library of shared stencils, which you can now search from within OmniGraffle, there is a pretty good case for using OmniGraffle.

Figure 2—A modified Android 4.0 stencil

A modified Android 4.0 stencil

Templates

“Stencils save me the most work, but templates are a close second when it comes to time savings.”

Stencils save me the most work, but templates are a close second when it comes to time savings. If I go from a project where I’m working on an iPhone app to one where I’m designing for multiple platforms—say iPad, iPhone, and Android Phone—templates like that shown in Figure 3 minimize my ramp-up time. I don’t have to do any research to find out the latest screen sizes and resolutions or spend time making custom elements match current design guidelines. Instead, I just open up our latest in-house template folder and pick the platforms that I need.

Figure 3—Android 4.0 device template

Android 4.0 device template

Template sharing isn’t as simple or as common as stencil sharing, so you may have to create your own templates, but the investment is worth it. Just a few settings templates keep me from having to configure settings each time I create a wireframe, including settings for canvas size, major and minor grid spacing, page orientation, units, snap to grid, device status bar, and guides.

Lastly, the greatest benefit of templates is consistency across different people’s designs. So, if people go on vacation and someone else needs to make changes to their OmniGraffle documents, diving in is much less complicated when everyone is working within a familiar template.

AppleScript Support

“Using OmniGraffle results in smaller files for your final deliverables, and using AppleScript makes updating your screens very simple.”

If you use Creative Suite to put documents together for client work or presentations, but wireframe using another tool, I can guarantee you that using OmniGraffle results in smaller files for your final deliverables, and using AppleScript makes updating your screens very simple.

But there is one problem: If you export all of your canvases from OmniGraffle to a single PDF to reduce the file size, when you place the screens in InDesign, it will use the page numbers in the PDF for reference linking. Then, if you add canvases or reorder them in OmniGraffle, their numbering gets out of order.

However, using AppleScript, you can create and run a custom script that lets you save each canvas in a separate PDF. Figure 4 shows the script that I use for this purpose. This lets you link each screen to a particular file—for example, document_canvasname.pdf—so if you reorder, add, or change screens, their placement is preserved. With my current workflow, once I’d figured this out, I concluded that it would take a lot to get me to switch from OmniGraffle to another wireframing tool.

Figure 4—AppleScript to manage the numbering of canvases

tell application "OmniGraffle Professional 5"
    activate
    set theDocument to front document
    set theCanvases to every canvas of theDocument
    set fileName to (name of theDocument)
    set filePath to (path of theDocument)
    set fileDirectory to "blank"
    set canvasCount to count of canvases of theDocument
    try
        tell application "Finder"
            set nFilePath to (POSIX file filePath) as alias
            set nFileName to name of nFilePath
            set nFileExtension to name extension of nFilePath
            set fileDirectory to container of nFilePath
            set fileName to name of nFileName
            set filePath to nFilePath
            log "File Name: " & fileName
            log "File Path: " & filePath
            log "File Dir: " & fileDirectory
        end tell
    end try
    set area type of current export settings to current canvas
    repeat with canvasNumber from 1 to canvasCount
        set cName to name of canvas canvasNumber of theDocument
        set cName to cName's words as string
        set canvas of front window to canvas canvasNumber of theDocument
        set saveLocation to ((fileDirectory as text) & "_screens:" & fileName & "-" & cName & ".pdf")
        log saveLocation
        save theDocument in (saveLocation)
    end repeat
end tell

Team Syncing

“The way OmniGraffle saves stencils and templates makes it very easy to update versions across a team, using a few other resources like Dropbox and AppleScript.”

The way OmniGraffle saves stencils and templates makes it very easy to update versions across a team, using a few other resources like Dropbox and AppleScript. Since everyone always has an up-to-date set of stencils and templates, we’re always wireframing at the bleeding edge—and roll in beta features before they’re even released. One person can manage the updating of stencils as platform updates come out, and the rest of the team benefits. The AppleScript shown in Figure 5 can serve as a starting point for syncing your team’s stencils with Dropbox.

Figure 5—AppleScript for Dropbox sync

Note—For this script to work you need to copy the entire "OmniGraffle" folder from /Users/USERNAME/Library/Application Support/The Omni Group/ to your shared Dropbox location.

tell application "Finder"
    set OriginalFiles to (path to documents folder from user domain) & "Dropbox:YourFolderHere" as Unicode text
    if exists OriginalFiles then
        --Display dialog "Dropbox within Documents Folder-" & OriginalFiles
    else
        --Check another location / error handling
    end if
end tell
set DestFiles to (path to application support from user domain) & "The Omni Group:" as Unicode text
log "Destination: " & POSIX path of DestFiles
try
    set userScripts to (path to library folder from user domain) as Unicode text
    set userScripts to (POSIX path of userScripts) & "Scripts/"
    --Pair 1 - if you have existing stencils installed, this first pair will copy new / updated items
    log "trying pair 1 …"
    try
        do shell script "rsync -vrut --existing '" & (POSIX path of OriginalFiles) & "' '" & (POSIX path of DestFiles) & "'"
    on error
        log "error: pair 1 --  rsync -vrut --existing '" & (POSIX path of OriginalFiles) & "' '" & (POSIX path of DestFiles) & "'"
    end try
    --End Pair 1
    --Pair 2 - default copy method
    log "trying pair 2…"
    try
        do shell script "rsync -vrut '" & (POSIX path of OriginalFiles) & "' '" & (POSIX path of DestFiles) & "'"
    on error
        log "error: pair 2 --  rsync -vrut '" & (POSIX path of OriginalFiles) & "' '" & (POSIX path of DestFiles) & "'"
    end try
    --End Pair 2
    --Copies custom script folder to local location
    do shell script "rsync -vrut '" & (POSIX path of OriginalFiles) & "/Scripts/' '" & (POSIX path of userScripts) & "'"
    log "finished copying all files…" --
    --Display dialog "Finished copying Stencils and Templates"
on error errText number errNum
    display dialog "Error copying files: " & errNum & return & errText
end try

Layers

“OmniGraffle lets you have layers on a canvas and even share layers across canvases.”

Layers have many different purposes. In the past, my primary reason for employing layers was to reduce rework. OmniGraffle lets you have layers on a canvas and even share layers across canvases. However, I’ve found that rather than managing the mental workload of organizing, planning, and maintaining different layers, it’s easier to just copy canvases—objects and all. You might think this would be wasteful in light of what you’re trying to do, but I find that, it’s so easy to change things in OmniGraffle in comparison to other applications, copying canvases saves me time. As you learn OmniGraffle, you might be tempted to weave in layers, but I’d advise your keeping things flat to make your wireframes easier to cope with mentally.

Where OmniGraffle Misses

OmniGraffle falls short when you’re designing responsive layouts. For those, I turn to either InDesign or HTML/CSS.

Complaints about OmniGraffle’s not handling pixel-perfect designs well enough are warranted. However, I’d question the assumption that you need exact pixel accuracy in your wireframes. I just give myself two to five pixels of wiggle room in OmniGraffle, and that works great.

OmniGraffle falls short when you’re designing responsive layouts. For those, I turn to either InDesign or HTML/CSS. The Adobe Edge suite also appears promising. Once the full beta is out, I’ll be curious to see how it might improve my workflow. You could employ static sizes in OmniGraffle, but whether you’d want to do that depends on your responsive workflow philosophy.

Another area in which OmniGraffle is deficient is communicating the interactions that are so crucial in native mobile app development. Clickable prototypes don’t cut it. I’ve found only a few tools that give me the freedom I need to explore interactions with non-standard behaviors—and most of what I do involves staying ahead of the curve and trying crazy stuff. I’ve tried more than 60 prototyping tools for native and Web applications. The two I’m most excited about are Proto.io and Edge Animate. Proto.io takes a more simplistic approach to custom interactions, while Edge Animate allows key framing and even custom coding. Videos work in a pinch, but their downside is that you can’t do usability testing with them.

While OmniGraffle’s lack of custom interactivity is a big deficiency, the pros of OmniGraffle still outweigh the cons for me. Perhaps I wouldn’t be happy even if OmniGraffle did handle interactions the way I think I’d want it to. It would probably bloat the application and slow down my wireframing, which would be frustrating. Of course, the Omni Group could prove me wrong by nailing an implementation of interactive prototyping, so I’ll let them decide whether they should pursue this goal. I love what they’ve done so far, and I’ll trust them to keep doing things right.

OmniGraffle Still Wins

“I haven’t found another wireframing application that matches OmniGraffle’s ability to … wireframe without an application’s functionality and features getting in the way of capturing my ideas.”

In conclusion, I haven’t found another wireframing application that matches OmniGraffle’s ability to

  • help me manage wireframe fidelity through stencils
  • visually display all stencil objects at once
  • customize templates for specific purposes such as user flows, branded sitemaps, Windows phones, and Android x 3+ device sizes
  • and most important, wireframe without an application’s functionality and features getting in the way of capturing my ideas

OmniGraffle’s greatest competitive advantage is that it focuses solely on wireframing. OmniGraffle lets you build off the work of others by using stencils and templates, so the more people who use OmniGraffle and share their work, the more everyone benefits.

4 Comments

I wireframe in Axure—and will go head to head with anyone wireframing using OminGraffle—and have never lost on either speed or quality. Axure is by far the most powerful layout tool I know of and is, therefore, faster. Same goes for its intelligent widget libraries, which are massively more powerful than OmniGraffle stencils.

I have trained lots UX designers, who are now ex-OmniGraffle users, on Axure, and all of them have found the same thing. This is not surprising since Axure was designed specifically for this purpose—unlike Omnigraffle—among many other things related to UX design.

I have met many people who claim diagramming tools like Omnigraffle are better, but that is usually for two interrelated reasons:

  • They have many years invested in using a diagramming tool, but don’t invest the same time learning a modern tool like Axure.
  • They don’t understand how to use or are even unaware of the more powerful layout features of a modern tool like Axure.

Then, of course, there is the issue that you have to re-key everything if you want to produce a working prototype in something like Axure—a big waste of time! Same thing when you want to do your pixel-perfect final design! Axure can do all of this in one application, plus lots more.

So, I’ll definitely be sticking with Axure for my agile UX work.

I’m willing to be proven otherwise, but Balsamiq is hard to beat for early sketching.

With a group of collaborators, whiteboards and photos of the whiteboard sketches are a great start.

I’m always keeping an eye open for how quickly can we generate multiple design ideas and throw them away, if necessary, to start again. Another issue has to do with how open the team is to more fundamental new ideas. If a project is really open to only a few tweaks, then by all means use a deep wireframing / prototyping tool.

Thanks,

— Joe

This is an interesting debate—Axure vs Omnigraffle. Perhaps the debate was so created by Rich, the article’s author. But I feel I have a unique perspective because I have used all four of these tools for agile and waterfall projects:

  • Visio
  • OmniGraffle
  • Axure
  • Justinmind Prototyper

I have also downloaded the trial version of Balsamiq. I think it does look very powerful and user friendly, but I don’t know enough about it to rank it against the above four. What I do know is that wireframes alone do not demonstrate a concept’s intended interaction design to an audience, whereas prototypes created with Axure and Justinmind do allow an information architect to demo an interaction design. Now, the pros and cons…

Pros of Prototypes Over Diagramming Tools Like Visio and OmniGraffle

  1. If you are able to publish an HTML version of your prototype someplace where your team or audience can play around with it at their convenience, you’re going to get much better feedback—and hence, weed out lots more potential problems earlier in your software development lifecyce—whether agile, waterfall, or otherwise. I found Justinmind superior to Axure in this respect. You can output prototypes to HTML, then publish them somewhere on your intranet/network; or
  2. If used properly, prototyping tools like Axure and Justinmind—and presumably Balmsamiq—can generate specifications documents, or annotations, as a Microsoft Word document or in other formats—for example, output to PDF. And again, if used properly, one can use these features to eliminate the monolithic process of documenting annotations manually in Word or some other application). I found Axure to be superior to Justinmind in this respect. I have yet to meet an employer who wants to train their analysts—who don’t have UI or IA skillsets—to use rapid prototyping tools for the purpose of making annotations. I think purchasing the extra licenses are one reason. But you also have to train all those analysts to ramp up on the tool—and perhaps more difficult, get them to abandon their old-reliable Microsoft Word specifications documents and processes—which were implemented by Accenture or some other firm 10 years ago—and now your client refuses to abandon those formats!
  3. If you want to get really serious about teams collaborating on deliverables—that is, multiple IAs & analysts contributing to the same project—the prototyping tools have built-in capabilities to work with file management programs like SVN—for check in and check out. Axure calls these shared projects and devotes more of their proprietary features and user interface to this. But I think Justinmind more wisely leaves that up to you—that is, whether to use SVN/tortoiaw versus Sharepoint versus whatever—and then you can modify your project files using those features outside Justinmind. The reason I find Justinmind’s more hands-off approach better is because, when I used Axure, the integration of authentication was unnecessarily complicated—that is, when there are problems with check in and check out, it’s unclear who the problem child is: Axure? SVN? Some firewall or password-locked issue? The error messages are too cryptic. What I’m saying is that I think Axure might have wasted time and money trying to integrate shared projects when you can simply manage your own files with your shared project technology of choice. I think Justinmind realized this and spent more of their recent time and resources on building capabilities to simulate mobile and tablet design. (It comes with built-in widget libraries for iPhone and so on.) Axure people will have to forgive me, as I haven’t used the latest version, and I’m guessing they are not far behind on the same.

Now the Cons

  1. By generating interactive prototypes, you’ve set greater expectations for yourself—and perhaps put some of the HTML-only skillset people out of a job. This is the classic, “give them an inch and they want a foot.” I’ve had business analysts complain to me, “This button doesn’t work. Is that gonna be a problem? Should I file a bug?” And I’ve had developers trying to code off of my prototypes as if they were pixel perfect. (Ha! I’m no graphic designer.) Developers need to implement real designs, using fleshed out specs from an FRD (Functional Requirements Document), then pull pixel-perfect designs and design patterns from a style guide or style sheet. Sadly, I’ve found that smaller organizations often don’t have these kinds of documents. But the bottom line is that a picture—especially an interactive picture—speaks a thousand words, so your stakeholders are always going to gravitate to your rapid prototyping (RP) deliverables. I used to think it was only the visual learners who are guilty of this. Nope. It’s everyone. Everyone prefers a click-through prototype over an FRD, a style guide, or plain wireframes created with Visio or OmniGraffle.
  2. You’ve also created the problem that, now, people expect that your prototype demonstrates behavior for all use cases—not just the happy path. As a matter of personal pride, I’ve actually done this before—gone out of my way to build 25 dynamic panels for 25 use cases. But sadly, I angered my fellow architects because it’s not something they are accustomed to doing. (Then again, IAs using Visio 15 years ago often documented their use cases in a right column! I think most IAs are more comfortable wireframing one use case—and then either annotating the rest or letting the analysts or developers figure out the rest. So, I’m not sure this is so much a con as that you start spilling over into other roles and responsibilties. (Hopefully, those who are larger clients have analysts who document use cases and their various combinations and permutations in an FRD. But for those of you at smaller and midsize clients, who wear more hats, you’ve added that work to your own plate. And then, when the developers inevitably find those four use cases that you didn’t prototype, how is that handled? I think that every organization has to put together their own unique game plan for this. Perhaps we should consider this as a matter of job title? If you prefer to keep using Visio and OmniGraffle to create sitemaps and wireframes, call yourself an Information Architect. If you’re making the leap into RP tools and dynamic panels and are prototyping more use cases yourself, call yourself a User Experience Architect?!

I have a lot more to say, but my fingers are tired. Maybe more later…

Where can I get the stencil you showed in this article, in Figure 2—A modified Android 4.0 stencil?

I couldn’t find it on Graffletopia. Did you make it on your own? If possible, would you share it publicly? I really want a good looking ICS stencil with low fidelity.

Join the Discussion

Asterisks (*) indicate required information.