ExperienceBlogger

I could write a looooong post on this and cite a bunch of examples, but I think that because I’m posting this using Tumblr, I’ll just stick with their masterful execution of this design concept.

“Back to the Top” Button

If you use Tumblr for your blogging needs, I’m sure this looks familiar:

It’s the helpful button Tumblr displays after you’ve scrolled too far down on your dashbaord and want to get back to the top of the page.  You click it, and “wooooooosh!”, you’re back at the top (side note:  they actually force the scroll to occur, versus anchoring you back to the top — here’s a great site about using motion graphics in the user interface I posted about a few weeks ago:  UI-Transitions.com).

Why is This Worth Writing About?

Think about it, how many times do you scroll all the way down on a page and there’s no “back to the top” link, and you waste several seconds scrolling back up?

Multiply that several seconds out for the thousands (or tens of thousands) of times you do that in a given month or year and you’ll see that you’re wasting valuable time (7 seconds x 10,000 scrolls per year = 70,000 seconds or almost 19 hours!) — I could’ve watched 2 seasons of The Wire in that amount of time!  Some things in life are just more important than scrolling  ;)

Tumblr’s implementation of this button is also really slick…

It’s not a permanent fixture on the page - it only appears after you scroll down.  And it doesn’t appear until you’ve scrolled down past a certain point on the page, otherwise, it probably would just be faster to scroll back up (as opposed to moving your mouse cursor to the upper right corner and clicking the button).

Look for ways to implement features like this in your app — try to discover what seemingly simple actions your users execute most frequently and try to streamline them.  It’s obviously not going to be a game changer for your product, but it’s one of those things that if done often and consistently enough, will improve the overall experience and perception of your product dramatically.

(NOTE:  This is the long form version of a series of separate posts on this topic)

Introduction

I’ve been building software and websites for close to 15 years now.  Although I’ve never been formally trained as a designer, I’ve found a process for conceptualizing and designing new web and software applications that works for me.   I hope that you enjoy this series and learn something new from it.

Here’s what we’ll be going over:

1. Defining the Goals for the Site - skip ahead»
2. Defining the Goals of a Single Page - skip ahead»
3. Sketching the Page - skip ahead»
4. Rapid Prototyping with Omnigraffle - skip ahead»

So here goes…

Define Your Goals

In my opinion, it’s more important to first define “why” you’re building something, than to simply define “what” you’re building.

So before you kick off any new product, page, etc., spend a few minutes fleshing out the goals for what you’re about to build.  Basically, provide a “reason why” for everything you’re about to design.  Here’s how we typically break things down:

User Goals:  First and foremost, we focus on the user.  It’s helpful if you can incorporate some user research into your process up front (e.g. interviews, personas, etc.) but many times early stage start-ups don’t have the time or resources.

Don’t worry, it’s OK to skip the formal/rigorous user research phase when you’re building your first prototype – especially if you follow the 37 Signals mantra of “design what you know”.  But be sure to constantly test and improve upon those prototypes based on real user feedback going forward.  Make sure your initial “guesses” about what they want pan out.  And if they don’t, make sure you have a process in place to improve based on customer feedback.

It helps to ask questions like:

• Why is this site valuable to my target customer?
• What can my site do to help make someone’s life better?
• How can I make it easier for them to execute those activities?

Once you understand the purpose of the site from the user’s perspective, it’s time to think about why the site is important to YOU and YOUR business!

Business Goals:  This step tends to be easier for most folks to think through (at least it is for me).  You’re basically asking yourself what activities you want the user to engage in that speak directly to your core business objectives.  So ask questions like:

• What are the MOST valuable actions a user can take on this site/page? (e.g. purchasing a product, registering for a newsletter, referring a friend, etc.)
• What can I do to make it as easy as possible for them to take this action?
• How can I measure the impact of this action?

I tend to rank my business goals on a per-page basis, which then helps me prioritize various visual elements later on.  But more on that in a bit.

Now that you know “why” you’re building your site, you need to design a structure that will ensure the “what” ultimately matches with the “why”.  What I like to do here is create a basic sitemap.

Create a Sitemap

It’s tempting to skip this step.  I mean, I usually have a decent idea of what I want to include in the site, so it seems redundant to spend a couple of hours creating a map of the whole thing.  But a word of caution: every time I try to break this rule and dive right into designing a page without a sitemap in place, I end up screwing myself big time!  I’ll ultimately end up scrapping whatever design I was working on and eventually I have to start over with a sitemap.

Once you’re done, take a step back and review your sitemap against your goals – does the “what” speak to the “why”?

Now that we know why we’re building this site, and we have a good idea of what the whole thing will look like, we need to start diving into the individual pages.

Cores & Paths

I first heard about the Cores & Paths framework from a presentation by Are Halland, and it’s meant to help:

• Prioritize content on the page
• Inform and delineate clear “Paths” for people to get to the page
• Inform and delineate clear “Paths” for people to leave the page

There’s even a dead simple worksheet that I use to make sure the framework is applied correctly:

The presentation slides (click here to view them) should give you a solid overview of how the process works, but I wanted to go through it briefly here as well.

Remember, none of this is set in stone.  It’s not a “required” part of the design process.  This is just a tool I find to be helpful as I’m working through my process.  But at the end of the day you need to go with a process that works best for you and your particular set of circumstances.

1.  The Cores

The “cores” of a page are the primary pieces of content and functionality you want your users to see and interact with.

When you create the cores, you’re trying to prioritize content based on the user’s goals.

So let’s say you’re designing an article page for a blog, you’d want to speak to a few key user goals:

• The user must know that they’re on the right page
• The user must be able to quickly scan the page and extract the content she came there for
• Sometimes the date and time the article was published will be important for the user to know

Those three simple goals would speak to creating a page with a prominent headline, a visible date & time stamp and an article body that begins as far above the fold as possible.

That was a simplistic example, but I think the point is clear:  List out all of the core content and features, then prioritize accordingly based on the user’s goals.

2.  The Paths

The next step is to design all of the paths a user would take to enter and to leave the page.

So break your Paths down into 2 categories: Inward Paths and Outward Paths.

Inward Path Examples:

• Search engine results page
• Ad banner
• Link from another page within the site (specify the other page)
• Etc.

The point in going through this exercise speaks to both your sitemap (which informs your navigation and overall site structure) and your marketing funnels.

For each path a user could take to your page, you want to be sure you have something on the page that speaks to that path (or helps them discover other paths).  For instance, if a user could reach your article page by first clicking on an article category link, you’ll want to include that category name somewhere in your page.  For example:



Again, this isn’t a “silver bullet”, it is simply a brainstorming tool to help you fully think through a design problem and potential solutions.

Outward Path Examples

Where “cores” primarily speak to user goals, Outward Paths speak directly to your business goals.  This is where we bring in the “business goals” list we made earlier.

Let’s use the blog article example again.  So your hypothetical list of business goals might look like this:

• Get a user to sign up for my weekly newsletter
• Get a user to send my articles to their friends
• Get a user to bookmark my page

So you might consider including these design elements on your article page:

• A lightbox that appears on a user’s first visit that prompts them to sign-up for your free e-letter
• A “Send to Friend” call-to-action button at the top AND bottom of your article
• A series of social bookmarking links at the top and bottom of your article
• And the list goes on…

I highly recommend using the worksheet I linked to above.  It’s really helpful when applying this framework and getting to the next phase in the whole process: sketching!

Get Ready to Sketch…

This is my favorite part of the entire wireframing process!

We’ve nailed the user’s goals.

We’ve got our business goals.

We even have the overall site structure and paths into and out of each page down cold.

Now it’s time to put pen to paper and start bringing our page to life!

3 Steps to an Effective Wireframe

I usually break up my sketching into 3 parts:

1.  Brainstorming - This is where I quickly do a bunch of thumbnail sketches with no particular goal in mind other than to get down several decent ideas of what I think the page should look like.  I’m not thinking about usability here or information hierarchy – I’m just trying to get as many different ideas out of my head as possible.

Here are some examples of sketches I’ve done in this phase (this was for an interactive Quiz feature we were adding to our classroom platform on TycoonU):



The goal here is NOT to have a final layout, UI, etc. for the page.  It’s to get some ideas out of your head, onto a piece of paper and get the creative juices flowing.

2.  Lists & Chunks - I actually got this tactic from a video presentation I found on YouTube.  I can’t seem to find it anymore, so if you happen upon it, please let me know.

In this phase I’ll put together all of the steps I’ve taken thus far (look at my cores & paths work sheet, check out the sketches I was just working on and even go back and review my sitemap and materials from my user research).

I’ll think about the navigation, graphical items, buttons and copy.  Pretty much every single thing that should/could be on the page.

Then I’ll list each and every one of them like this:



Once I have a fairly comprehensive list (don’t worry, I always miss something and add it in later) I go through a process called “chunking”.  It’s where I group related items together into “chunks”:



I’ll then draw each chunk as its own separate area on a page and create a “lo-fi” wireframe (as opposed to a “hi-fi” wireframe which most folks are used to seeing).  I find that, by creating the lo-fi wireframe first, I can focus on page layout and information hierarchy, without getting mired in the muck.

It allows me to make changes and refine my ideas much faster than if I had drawn out a hi-fi wireframe.  Here’s an example:



Once I have my “chunks” laid out, I move on to the final phase in this step of the process…

3.  Fleshing it Out - In the final phase I move from broad chunks into well-defined page elements.  However, I don’t draw the entire page at the same time.

Instead, I draw each chunk individually.

This way I can focus all of my attention on small areas of the page at a time.  I can put all of my energy into making each chunk perfect.

Once each chunk is complete, I’ll pull everything together (I sometimes cut out pieces of index cards and do this on a whiteboard) into a cohesive wireframe sketch.

Here’s the finished pencil sketch for the quiz page:

From here, I sometimes refine the sketch a bit further, depending on what I think.

Omnigraffle

So let’s quickly re-cap where we are in this process:

1. We’ve defined our User Goals
2. We’ve defined our Business Goals
3. We’ve defined explicit paths into and out of our pages
4. We’ve broken the page down into “chunks”
5. We’ve sketched out each chunk and pulled them all together into a well defined wireframe

Now it’s time to get our wireframe out of our sketchbook and onto the computer.

Some Tips and Tricks

Disclaimer:  Before we get started, be forewarned: The following mainly applies to those who use Omnigraffle for their wireframing.  I’ve used other tools before (Visio, Axure, etc.), but now that I’ve moved to a Mac, I solely use Omnigraffle.

I’m not going to bore you with a lame tutorial on “how to use Omnigraffle” — hell, I’m sure I’m not even using it right.  Instead I’d like to share a few tips and tricks I’ve picked up that help me create wireframes more quickly, communicate them more effectively to project stakeholders, and ultimately get a solid product out the door.

1.  Stencil Libraries

Omnigraffle comes with some basic stencil libraries.  I guess they’re useful to some folks, but when it comes to wireframing sites, the basic libraries suck.

So I highly recommend downloading one of the following:

• Konigi Wireframe Stencils:  This is by far my favorite stencil library out there.  They also have a TON of other great resources on this site.  I can’t recommend it enough!  The only downside here is that the library is limited to Omnigraffle.

• Yahoo! Design Stencil Kit:  Yahoo’s Design Stencil Kit is definitely a close 2nd Place on my list.  The great thing about it is that they have libraries for Omnigraffle, Visio, Axure, InDesign and the list goes on.  Definitely check it out.

There are plenty more out there – these are just the two I use most often.

2.  Shared Layers

When I first started using Omnigraffle, I would literally copy & paste common visual elements (e.g. navigation, logo, etc.) onto each new canvas I created.

On a site with over 100 pages, that could become rather time consuming.

If you have any real experience with Omnigraffle then I imagine you’re laughing at me right now.

It took me a while, but I finally found out that Omnigraffle has shared layers (similar to layers in Photoshop) where you create a layer once and it’s then duplicated on every new canvas you add to the project.

Now, when I begin a new design project, I’ll name my first canvas “Master” and add one or more shared layers to it to represent various common elements I’ll need throughout the design:

• Logo
• Site navigation
• Footer
• Column borders
• Etc.

This helps keep my design consistent, cuts down on needless work as I create new pages and makes it very easy to add or modify one of these common elements over time.

Just like the stencil libraries, this is a HUGE time saver.

3.  Use Real Content

While I’ll sometimes use “lorem ipsum” text, I do my best not to make it a habit.

Site copy and content are just as important to the design as button placement and navigational elements.

There’s no way you can predict how the page will look “in the wild” if you don’t use real content. This is especially true for user generated content sites.

So I’ll still use the stuff from time to time, but I do my best not to and it’s served me well.

4.  When in Doubt, Create an Interactive Wireframe

There are times when I just can’t tell if a design “feels” right.

The layout looks fine, I have the interactions properly documented and annotated on the wireframe, I can almost picture how it’ll flow… but something just isn’t giving me that “warm and fuzzy” feeling I’m looking for.

Luckily, Omnigraffle makes it pretty easy to create an interactive prototype out of your static wireframes.

I could go into how to do it here but there are a ton of articles on the topic, here’s one that’ll show you how it’s done:  Prototyping with Omnigraffle.

Once you have an interactive prototype set up, you get to play with “the site” before the developers ever touch it.  This is a super fast and cheap way to find interaction and usability problems very early on in the process.

Not only that, but it’s also great for:

• Putting your design in front of real users early on.  This is actually the best way to test your design.  If you’re the one designing the page and doing the testing, you’ll never be able to look at it objectively.  Get this in front of a couple of people who haven’t seen the site yet and you’ll be stunned with how much you learn!

• Communicating the design to “business folks”.  While I think everyone in my company is fairly tech savvy, there are still plenty of folks who just can’t quite picture what a finished product will look like when they’re staring at a wireframe.  Their ability to give feedback is limited and I sometimes run into funky situations at the end of a project.  The interactive prototype has really helped me get everyone on the same page before any costly mistakes are made.

Wrapping Up…

So there it is, my wireframing process in a nutshell.

I hope you enjoyed this post and got something of value out of it. 

At the end of the day, I’ve never been formally trained in UX/UI.  But I’m passionate about building things that help people and I’m constantly looking to evolve and improve my process.

So please send me some feedback or share some ideas on what works for you when you’re planning and designing a new site.  I’d love to hear from you.