Before you begin coding it's important to take a few preliminary steps. What follows is a technique I use for gathering all the blocks of information that will ultimately make up a websites story, establish a layout, and define the user experience.
I'm going to make the assumption that you have conducted basic client discovery and subject research for your project.
The goal of this method of information architecting is to use index cards to create a physical inventory of possible information components. It's best to do this exercise with others, especially stakeholders in the project. Here are the steps I follow:
Step 1: Write down in a word or two on an index card what the card represents: content, function, a navigational element, an image, video, whatever.
Think of as many components to the page or application as you can – I prefer dealing with a single view at a time, like the homepage.
Color coding is helpful. For example, the navigation area could be green while the main body is blue. A pack of 200 index cards sell for under a dollar so don't be afraid to get nitty-gritty with what you define as an information component.
Step 2: Lay out the index cards on a table, organize them into logical groups like navigational or footer areas.
The surface area of the table represents your viewport.
Step 3: Review the cards on the table and start eliminating the cards that you don't want to include. Don't be conservative in eliminating.
KISS (keep it simple stupid)
- The Front End Manifesto
I find that the process I just described works best for me, but there are other ways to go about the index card exercise. Tweak my method until it works right for you, your team, or your clients.
Check out how this design group uses index cards:
Lately, I have been scanning my index cards and organizing them directly onto a wireframe:
You can use a digital equivalent to index cards like PowerPoint, or even a single sheet of paper (as a list of items), but index cards are best (IMHO).
Introducing the ViewThought Case Study
Here's a practical example and a proof of concept. I need a new website for my practice "View Thought". My storyline goes something like this:
We are a great website design, development and user experience shop. We have tons of experience, have worked with a bunch of different clients who are all happy with our work, and we really care about what we do. We specialize in Ruby on Rails, and we pay special attention to what your users will see. You should hire us! ...or give us a call and learn more.
Start Index Carding
I immediately can see a few index card entries in my storyline and start indexing everything I can think of. It's good practice to do some basic research as well. Besides my own ideas I also research what competitors or similar services are doing with their websites.
Bookmark research sites to review and reference throughout the process. It's sometimes helpful to add a simple tally on the bottom of index cards to see how many sites referenced used that particular element:
NOTE: The "/" separates the different word choices used by referenced sites to express the same thing.
Laying It All Out on the Table
After completing Step 2 here is what my index cards look like laid out on a table:
I have 200 index cards laid out and grouped as navigation, content, or footer information. As I review I begin to remove index cards (components) I don't plan to use.
I also start to think about where information will be placed and shuffle things around. I want to call attention to different parts of the story depending on its relevance and importance to the storyline. I move index cards with these components higher up on the table.
Basically I think like a newspaper layout editor, and after evaluating and reorganizing here is what I'm left with:
Quite a bit less and through the process of research, writing things down, and moving index cards around I really have a great grasp on what my site will look like and how I'm going to start coding.
Patterns Are Good but Don't Get Stuck in Them
Before we move on there is one thing I noticed myself doing in the exercise that I'm not too crazy about: assuming that there would be a traditional header, body, and footer. Chances are there will be, but I don't like the idea of boxing myself in so early on in the project. My thoughts on this are:
You have to start somewhere, but keep an open mind. Move things around and experiment. Keep your ego out of it, and when you start coding you can always break free–if it makes better sense.
Mobile First and Information Architecting
So things look good. I defined and organized all of my information blocks, and laid out the blueprint for designing my website, but something is wrong. I haven't addressed mobile.
Mobile devices require software development teams to focus on only the most important data and actions in an application. There simply isn't room in a 320 by 480 pixel screen for extraneous, unnecessary elements. You have to prioritize.
- Luke Wroblewski in his 2009 article "Mobile First"
I need to address mobile, and my approach to doing so comes from an experience I had years ago when I worked for Fidelity Investments' FEB Design unit in Boston. Myself and a colleague were asked to convert an existing Fidelity desktop application to a mobile experience, pre-smartphone era.
Since the desktop application already existed my colleague and I began by whittling down, redefining, and regrouping what was already there for the smaller screen size experience. The end result was not only a mobile app, but a precise definition of the "what-is-really-important" information architecture, no more no less.
By starting with an all-encompassing desktop version that included the kitchen sink and re-architecting for a smaller screen size we zeroed in on what was most important about the application. Several of our colleagues pointed this out to us and used the redesigned mobile application to improve the design of the larger desktop application.
In the example above I have the desktop experience laid out on the table, and this is good. Like in the experience at Fidelity, I now need to whittle it down even further.
Provide for the mobile experience as a forethought.
- The Front End Manifesto
After removing even more index cards here's what I'm left with, and don't worry if you can't read what's on the card, the point is look how fewer cards are now on the table:
And there you have it, the application in its absolute simplest form doing only the things that are most important. From here we can build up to the desktop.
The Importance of This Exercise
On a final note on index carding, as a front end developer with years of practice, a huge part of me just wants to bypass this exercise alltogether and start coding (and change things on the fly as I move along). So why don't I?
Experience has shown me that the manual process of labeling index cards and laying them out forces me to reflect and think outside of my coding box. It helps me discover new ideas, visualize and refine the information architecture, and not work in isolation (i.e. include others in the process). I find that by doing the exercise there's just enough chance of a better outcome that it's worth trying.
On a final note, as an intro to UX I highly recommend the book "Don't Make Me Think" by Steve Krug. It’s a good read and everything he says is so darn obvious you just might miss it, but thankfully Steve Krug puts it all there in one place for you.
Want to know when the next article is published? Subscribe here. Thanks for reading!