ExperienceBlogger

(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.

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 sketch book and onto the computer.

Some Tips and Tricks

Disclaimer:  Before we get started let me say that this post mainly applies to those who use Omnigraffle for their wireframes.  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 the details of 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 quicker, communicate them more effectively to project stakeholders and ultimately get a better finished product out the door.

1.  Stencil Libraries

Omnigraffle comes with some basic stencil libraries.  I guess they’re useful to some folks but if your job revolves around building the front-end UI for websites, 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.

Once you get either one of these setup you’ll be creating powerful wireframes in no time.

2.  Shared Layers

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

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

Now imagine when something needed to get changed — to go back and do it 100 times was just insane.

For those of you shaking your heads thinking, “Wow this guy is stupid”, let me just say that you’re absolutely right!

I finally found out that Omnigraffle has shared layers (similar to layers in Photoshop) where you create it 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 slides and makes it very easy to add or modify one of these common elements over time.

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

3.  Use Real Content

While I’m a fan of, and will 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.

I learned this lesson the hard way with TickerHound.

We were still in pre-launch mode and I had just finished my “final” draft of the wireframe for our most important page: The Question Details page (where you see the question + accompanying answers).

I did what most inexperienced designers do and used lorem ipsum text for almost everything on the page: from the question headline to the individual answers.

So we coded the page out, published to our beta server and I went ahead and asked the first question…

The question headline happened to be longer than the lorem ipsum text I used, it wrapped where it wasn’t supposed to and threw the alignment of the page off completely.

Like I said, I 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 setup 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 non-designers and non-developers.  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 produt 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.  You know, when the CEO uses the finished site for the first time and flips out because you used radio buttons instead of a drop-down list.  Meanwhile, you showed him the wireframe a month before and he didn’t say a word.  You can’t blame him, wireframes aren’t the most effective tool for communicating how a website will work.  But an interactive prototype - where anyone can click back and forth - will prevent those annoying situations from occurring too often.

Summary

I could go on and on here but these are probably the tactics that have saved me the most time and grief over the last few years.

I hope you enjoyed the whole series and found it helpful. I’ll probably compile everything into a single post at some point soon.

In the final version I’ll be sure to edit the hell out of each post to make them a little easier to read, include a better summary and a shit ton of links to other wireframing resources.

As always, please submit some feedback either here or email me at waynemulligan at g mail dot com.  Thanks!

This is my favorite part of the entire wireframing process!

We have our user research completed.

We’ve nailed the user’s goals.

We’ve got the business goals.

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

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

The Process

I usually break up my sketching into 3 parts:

1.  Brainstorming - This is where I just 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.  Just overall content, look & feel, structure, etc.

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):

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 look at some of the rough sketches I did, go back to my “Cores & Paths” document and then put my thinking cap on and deeply think through every single piece of content that belongs on a page.

I’ll think about the navigation, graphical items, buttons and copy.

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

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 these chunks as entire areas 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 layout and page structure without getting wrapped up in the details of button placement and typography.

It allows me to iterate faster and refine my ideas without investing a ton of time in tedious work.  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 independently.  It helps me focus on each page element.  I don’t get distracted by 20 other things going on and I can put all of my energy into making each chunk perfect.

Once each chunk is perfect, I’ll pull everything together (I sometimes cut out pieces of index cards and do this on a whiteboard - but only for more complex designs) 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.

Once I’m comfortable with the pencil sketch, it’s time to move everything onto the computer so I can get the visual designers on board.

Up Next…

In the next part of this series I’ll briefly go through some of the techniques I use when bringing a wireframe from my notebook to the computer.

This post is LOOONG overdue, my apologies for the delay.  This is the 2nd post in my series on wireframing. 

In my last post I talked about the benefits of user research and goal directed design.  We talked a bit about the benefits of a sitemap and also stressed the importance of establishing clear user goals and business goals at the outset of a project.

In this post I want to specifically talk about how both the user goals and the business goals inform the basic structure of a page.

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 a page (the “Cores”) based on user & business goals
• Inform and delineate clear “Paths” for people to get to a page
• Inform and delineate clear “Paths” for people to leave a page (calls to action)

The presentation slides 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 and is not a “required” part of the design process.  This is just one of many brainstorming tools I use to generate design solutions.  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 and preferences.

1.  Prioritize the Cores

When you create the “cores” of the page 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 you get the point:

List out all of the core content and features then prioritize accordingly based on the user’s goals.

2.  Design Inward Paths

The next step is to design all of the paths a user would take to reach this page.  For example:

• 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.  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:

Or if a user could arrive at your page via a search engine result listing, you might want to have a dynamic section of the page that displays the keywords they used in their search.

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

3.  Design Outward Paths

Here’s where we bring in the “business goals” list we made earlier.  Now, instead of speaking directly to a user’s motivations and goals for coming to your page, you’re going to try and get them to take an action that benefits you and your business.

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

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

• A lightbox that appears on a user’s first visit which 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…

Get Ready to Sketch…

Now that you have a basic toolbox for thinking through your site structure, your user’s goals, your business goals and the different content and functionality that a page must contain, you’re just about ready to start sketching your first wireframes.

In the next post (trust me, it won’t take me 2 weeks to get the next one up) we’ll go over one of my favorite parts of this entire process: creating “content chunks” and your first pencil sketches of your page!

Cores & Paths Template

Click here if you’d like to download my Cores & Paths template.

This is the first post in my series on Wireframing. Enjoy!

Before I put pen to paper and begin to sketch out a site or page design, I go through a few key steps first:

1.  Define Your Goals:  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, before you even design it.  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.  But be sure to constantly test and iterate those prototypes against real users going forward (a later post will deal with user testing).

For those who can’t go through with some upfront user research, at the very least try to put an empathetic pair of goggles on and think from your user’s point of view.  It helps to ask questions like:

Why is this site valuable to your target customer?

What  can your site do that helps make their lives better?

How can you 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!

- Business Goals:  This step tends to be easier for most folks to think through.  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 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.  I also find it helpful to limit the number of business goals per page to 3 (ideally, it’s just 1).  This helps keep my design tight and focus the desired action I want the user to take.

For example, on some of our old pages we used to have multiple calls-to-action.  We simply scattered them about the page and hoped users would click on all of them (newsletter registration, sign-up for a free trial to a product, etc.).  It seems like common sense now, but it took us a while to figure out that we should probably eliminate (or at least conditionally display) the newsletter sign-up area because the most valuable action a user could take on our site was to purchase a product.

2.  Create a Sitemap - I can’t even begin to stress how important this is.

Do NOT start designing a single page until you know how it fits into ALL of the other pages on your site.  Every time I try to break this rule, I end up screwing myself, scrapping whatever design I was working on and eventually I have to start over with a site map.

And please don’t skimp on the level of detail in the site map either - it might seem painful but it pays to not only show groups of pages, but try to show the entire process flow from page-to-page as well.  How does one page transition into the next?  How do all of the pages link to one another?

Once you can visualize a process, you can picture how a user will feel as they’re going through it.  This will help you identify points of friction and you can eliminate them BEFORE you even start designing the page.

Again, a site map is a MUST!

3.  Apply a Framework:  It’s easy to lose your way when you’re building a massive site, operating on a tight budget and a deadline is rapidly approaching.  You tend to cut corners in an effort to move faster.  I’ve been there, I understand.

I’m all for the quick and dirty approach to building a product - especially when we’re talking about an alpha version or MVP (Minimum Viable Product).

But there are frameworks you can apply to your process that won’t slow you down and will insure a design that incorporates both the user and business goals successfully.

In my next post I’ll go over a framework that we’ve come to depend on to quickly get a new page up and running!

Feedback

By the way, please feel free to submit some feedback on this post.  It’ll help me improve on the next one!

For the next few weeks I’ll be writing a series of posts on my wireframing process.  I’m still formulating the overall structure of the series but I think I have a good idea of how I want to break the content up.

But first, I’d like to offer up some “disclaimers” before diving into the series:

1.  I haven’t been “formally trained” in interaction design.  I went to an art high school (Manhattan High School of Art & Design represent!) and have independently studied design in one form or another for most of my life.  I’ve even gone to a number of seminars on User Experience and Interaction Design, most recently the Adaptive Path UX Intensive (which was GREAT btw). 

However, I’ve never had any rigorous, formal training in interaction design.  So I’m sure certain aspects of my process will be lacking relative to folks who have been formally trained and solely focus on interaction design to make their living.

But this is the process that works for me and has allowed to me research, plan and design dozens of sites and applications that are used by hundreds of thousands of people.

2.  I won’t cover interaction design basics.  This series is mainly here to illustrate the framework I use when I’m building a new site or web page.

And while it might not be critical for you to have a firm grasp of user experience and interaction design fundamentals, it will certainly help you in your endeavors if you go over some of these resources first:

• Jakob Nielsen’s 10 Heuristics for User Interface Design (click through on the “See Also” links at the bottom, GREAT stuff in there as well)
• Don’t Make me Think by Steve Krug
• The Design of Everyday Things by Donald Norman

3.  This series will primarily focus on the actual wireframing process, it will not encompass the visual design that comes after the wireframes are complete.  That’s where my expertise stops and I’m smart enough to outsource that task to those who are better suited for it than I.

However, I will include some pointers on how to find a good visual designer and more importantly, how to communication your vision to a visual designer.  This way everyone’s happy with the final product.

So expect my first post in this series in a few days.  I hope someone gets something of value from it!