How to Size Text in CSS – Richard Rutter describes various approaches for sizing web type in pixels, ems, and percentages. Rutter pioneered the “62.5% Method” for sizing web type, which I still use.

Five Simple Steps to Better Typography – Mark Boulton’s great blog post series on how to make the type on your website better. Nice, illustrated examples, very accessible to non-designers.

Compose to a Vertical Rhythm – Helped establish the use of a baseline grid, or vertical rhythm, for web typography.

Setting Type on the Web to a Baseline Grid – Wilson Miner shows you how to establish a baseline grid for your website, and how to make type of various sizes adhere to that grid.

Text Sizing – provides screenshots (lots of screenshots) of various browsers to compare text sizes.

I Love Typography – Not just web typography, but type in general. Beautiful site, lots of good coverage of all things type.

Web Design is 95% Typography – Great article that discusses the enormous role typography plays in web design.

Typography is the Foundation of Web Design – I couldn’t agree more with the title of this post. Samantha Warren discusses the process she uses for implementing great type solutions for the web in a presentation she gave at Refresh Baltimore.

The Elements of Typographic Style Applied to the Web – Great resource that takes Robert Bringhurst’s classic on typographic style and applies it to web design.

Web Safe Fonts – Great survey conducted by Jason Cranford Teague that details current web safe fonts and their presence on a variety of platforms and versions.

TypeTester – Lets you quickly and easily compare different typefaces and sizes, and generates CSS.

If you find any other useful resources, please share them!

Generally, my design process follows this flow: Brainstorm & Research → Concept → Mockups. Of course, the process never goes straight from one to the next, but meanders as ideas develop. That’s OK, so long as you have a process to begin with, and have good, thought-out reasons for going back and forth during the process.

The Process

Brainstorm and Research

The first part of the design process involves something humanists should be quite familiar with: research and brainstorming. Great design solutions take lots of research and lots of thought, and don’t simply appear out of thin air. A significant investment in brainstorming and research during the design process helps produce great results far more often than without.

When I begin a design project, I usually ask the project team or project lead what kind of mood or atmosphere we want the site to set for users. It is important to get feedback from the team at this point. I advise setting aside one or two meetings for this, just to come up with aesthetic concepts and sort through which ones are most useful, before touching Photoshop. When I asked this about Gulag, for instance, the responses were almost always “cold,” “grey,” “dreary,” “worn,” and “sad.” Create mood boards, find other websites that contains elements you like, create color palates, whatever works for you and your team. The point is to get those creative juices flowing, to come up with ideas no matter how crazy. I’ve found that if you get stakeholders involved at this point it helps head off issues when discussing design mockups later on in the process.

I keep an Idea Box in my office, and put things that I think are designed really well, or use design elements that I’d like to emulate in a future project. These things include magazine clippings, keychains, flyers, product boxes, coffee cup sleeves, anything that I think is designed well, has a strong concept, or implements interesting solutions. I also keep a library of website screenshots that I like using iPhoto. I regularly check out CSS showcase sites like CSS Mania, CSS Beauty, and Stylegala, to name a few. Sometimes I’ll take shots of the entire screen, and sometimes I’ll take clips of particular portions of a site I like, such as forms, headings, lists, or navigation. All of these serve to get ideas flowing in my head, figure out how others have solved design solutions, and learn from them.

Screenshot of Gulag: Many Days, Many Lives.

Important for designers in general, but especially important for digital humanists, is researching the materials presented on the site. I look at materials not to engage them as an historian, but as a designer (though I can’t help but look at them as an historian too). I look for the emotions the materials evoke, for ideas to draw from, for inspiration. For Gulag, there were lots of photos, drawings, letters, and posters on the history of the Soviet Gulag prison system that provided a wealth of design inspiration. I was drawn to a particular photo that depicted the remnants of a barren camp, and decided that would serve as the centerpiece for my design.

The Omeka logo had a somewhat similar development. From a design perspective, Omeka has been one of our more difficult projects to design and market, because we want to appeal to so many audiences: We want it to appeal to a general public, but also to have a professional, academic air to it. As it says on the Omeka website, the term “Omeka” is Swahili for “display goods, to unpack,” so we wanted something that embodied that idea too. So, I researched potential sites that could be built with Omeka and looked at sites that our target audience created.

At this stage, I use pencil and paper a lot. Before I touch Photoshop, I sketch ideas, usually thumbnail-sized boxes with layout, color, and graphics ideas. I like to keep a regular notebook for sketching ideas for various projects. I have a box full of crayons and colored pencils. I try out color combinations on paper and quickly draw logo ideas and layout ideas. These help me explore concepts quickly, without the investment of time and energy it takes to sketch ideas on the computer.

Concept

The whole goal of design, for the web or otherwise, is devising and implementing a concept or solution for a specific problem. If you do not have a concept—if you choose images, colors, fonts, et cetera with no reason—you’re decorating, not designing. Designers should have a reason for almost every design decision: fonts, font size, font weight, leading and kerning, margins, padding, layout, colors, widths and heights, images. Design does not implement these things haphazardly.

For Gulag, my concept was simple: a cold, snowy camp, isolated and desolate. I took the photo of the camp I had found and made a Photoshop brush of the building and fence, then created a white silhouette of the camp that blended into the white background of the content area of the site, giving the sense that the camp in the header held or contained the content below. The logo employs a font called P22 Johnston Underground which, besides being similar to the font used for the London Underground, is reminiscent of fonts also used in Soviet propaganda posters. Thus, my design for the site combined a rugged, worn, desolate camp with a bureaucratic, constructivist attitude.

Logo for Omeka.

For the Omeka logo, my concept involved modifications to the “unrolling” or “unraveling” that we initially came up with as a team. I liked the idea of a spiral, but also felt that the spiral should have direction, and not seem like a spiral out of control. One of the strengths of Omeka is its structure and ability to frame and guide the creation of an archive or exhibit. So, instead of a random spiral, I used the Fibonacci spiral to indicate unrolling, but in a systematic, controlled, directed way. The path in the logo represents the seemingly endless and creative ways you can use Omeka, while the ratio of squares and rectangles represents the framework and guidance that Omeka provides.

Humanist scholars should see the utility in having a purpose for doing something; we usually have a purpose all the time, whenever we write a paper, give a lecture, or contribute to a conference. We always have a thesis, an argument that always tries to solve a problem or get a concept across to an audience. Design is no different. Good design always has a problem to solve, a concept to get across to an audience. Choices about color, typography, and layout should be solutions to that problem.

Mockups

Once you have a solid concept in place, now you move to creating substantial color mockups in Photoshop or another graphics editing program of your choice. At CHNM, we generally develop 2-3 different mockups, each with 2-3 levels of page: homepage, a “browse” or secondary page (like browsing the results of a search), and a “content” or tertiary page. Sometimes each mockup has its own concept, and sometimes all are simple variations on a central concept. The wireframes created in the previous phase come into play here. Ideally, the design team has enough information about what content will go on a page and how much to do a quality mockup. If they don’t have this, it is extremely difficult to do mockups. I almost always make a checklist of all the content elements that should appear on a page, and check them off when I have accounted for them. Adding new content elements can and usually does throw off the design.

As a personal rule, I always start with the most “inside-page” first, or the content/tertiary page. The inside page is arguably the most important page on the site, the page that your users are trying to get to and will want to use. The homepage and the browse pages are important, but only in the sense that they’re sole purpose is to help users find that last page of content, the one they’re going to use, for research or educational purposes. Think of a website review, an archive page for a single item in your database, or a blog post with comments. Your approach may be different, depending on the information architecture of your site, or your own personal style.

Screenshot of photoshop mockup I created for a redesign of the Western History Association website that illustrates use of guides for grid layout and typography.

While creating mockups, its good to keep a running list of design specs that you’ll need to translate into CSS when you begin front-end development. I pay particular attention to font sizes, margins, line-heights, and colors for various parts of text (paragraphs, headings 1-6, lists,etc.). I also think about the grid I’ll use for the page design. I use a very handy Photoshop script called GridMaker, that allows you to quickly create a grid of columns and gutters using values you input. I almost always design pages using a 12-column system, which allows for the most flexibility (2 divisions of 6 columns, 3 divisions of 4 columns, 4 divisions of 3 columns).

Photoshop Management

A few tips for doing mockups in Photoshop:

1. When making color mockups in Photoshop, I usually set the resolution to 300dpi, so that they print nicer and can be used in grant applications (which CHNM does a lot). You can bump them down to 72 dpi to use directly on your website if needed.
2. Name your layers. Let me say that again. Name your layers. It is so much easier for someone else on a project team to open your photoshop file and find a particular element on the page if you name your layers meaningfully. Don’t use a name like “layer 1″ because, well, that’s just not meaningful. I don’t have solid naming conventions, but it might be good practice to implement some.
3. Use layer groups. When I do a mockup, I generally have each page level I’m creating in its own folder, so I can work in one file and not three separate files. I also use folders for sections or groups of content.

Presenting and Discussing Design

A few quick tips/observations on some best approaches for presenting and discussing design:

• The design team should prepare a design brief, written or oral, to present to the project team on the design concept implemented for each mockup. Part of a designer’s role is to sell her/his design, to explain why she made certain design decisions and how they successfully apply the overall concept of the site. This helps in a few ways: 1) It allows your thought process concerning design decisions to be more open and available to the project team, and 2) in most cases, it will help you counter unhelpful feedback like “I don’t like orange.” by showing someone giving that kind of feedback how to provide more constructive, nuanced reasons.
• Stress that design isn’t about using favorites: favorite color, font, images, whatever. Design is about finding the right solution for your project. For example, I hate purple. I can’t stand it. But I’ve used in on several sites because I thought it provided the right solution for a concept we were considering. Similarly, Gill Sans is probably my favorite font, but I don’t use it on every site I make (even my own blog) because its not always the best design solution for a particular project.
• Resist design stenography. Design isn’t about simply taking orders or requests from someone and implementing them. “Change this color to red” isn’t design. This requires diligence and respect from all sides: especially the designers and the project managers. Compromises can easily be reached, with patience, respect, and intelligent discussion.
• Avoid “mix-and-match” design, or taking elements from multiple design concepts and combining them. If you’ve done the design carefully, and implemented each concept consistently, mixing design elements from different concepts will be counter-productive.
• Limit the number of feedback rounds and revisions, and avoid design-by-committee. A project can easily spend months on design revisions, and can end up including a dozen different people, each with her/his own opinions on a design. Its very easy for the project team to get bogged down in discussions of “I don’t like this color” or “that font is too big,” especially if this comes from way too many people. Too many cooks in the kitchen is an apt analogy. Set a specific round of revisions (I prefer to limit feedback to 2 rounds), and set the number
• Don’t be defensive. A designer on a team will invariably have to discuss design with people who aren’t designers and who don’t think and speak like designers. Getting defensive about design decisions will only create animosity among the team, and never leads to productive results. As a designer, part of my role is to demystifying the design process, to help non-designers understand how I approach a project as a designer.
• Be positive and diplomatic with feedback, and help other better articulate their reasons for critique There are a few ways to react to feedback. One way to react to someone not liking a particular color or font is to explain why you made that design choice to begin with (“I wanted to make this stand out because in our wireframes we wanted this piece of content to seem more important than the rest.”) and then ask whether they agree with my reasoning. For instance, I chose a font for a logo for a CHNM project, and a few folks on the project team didn’t like the font. I explained that I chose the font because I felt it conveyed a sense of what I called “professional playfulness” and that allowed others to better articulate why they didn’t like the font, in this case because they didn’t want the logo to exhibit playfulness. I was then better able to find out what idea they did want the logo to exhibit, and choose fonts accordingly.

Designer’s Toolkit

Here are a few things I keep in my toolkit and highly recommend:

• Pencil, Pen, Paper!!! – Colored pencils, markers, crayons, lots of scratch paper. Use ‘em, don’t be afraid to draw something stupid. Get ideas on paper, as many as you can. Design concepts evolve with thought and experimentation, so don’t be afraid to go crazy.
• Idea Box – Keep stuff you think is designed well, and think about why you think it is designed well.
• Photo album or collection – For screenshots and other images. I use iPhoto, but you could easily use Flickr or some other online service. I also have albums when doing research for a project, like Gulag. Half of the image catalog we have on the Gulag site is on my laptop, because I looked through them when doing research for the design.
• Photoshop and Illustrator, with a host of brushes, patterns, and plugins. Make brushes and patterns yourself, and export them so other memebers of your team can use them too.

Initial Steps

1. Determine genre
2. Content inventory/audit
3. Site Maps
4. Page wireframes

Genres

Collecting Sites/Online Archives

Online archives and online collecting sites provide an interesting challenge to defining site architecture. On one hand, they are challenging because the much of the content itself is continuously updated, and never finished. On the other, it can be easier to narrow down the scope of the kinds of content you want to collect and archive. Thus, collecting sites and online archives need to blend

An example of this kind of project is the Hurricane Digital Memory Bank. The goal of the project team when organizing HDMB was to feature the contributions from the public, and account for as many different kinds of contributions as possible: audio, video, images, and text. The site architecture of HDMB reflects a blend of hierarchical guidance and fluid exploration by the user, and is flexible enough to account for constantly-updated content, provided by the public.

Online Exhibits

The goal of online exhibits is to provide a structured, guided presentation of content to the user. Ideally, online exhibits combine an overarching narrative interspersed with relevant exhibit items or objects showcased from the exhibit archive.

In some cases, online exhibits organize content in very hierarchical, guided ways. Object of History, for instance, organizes its content around six featured objects, and asks visitors to explore each of those objects separately, associating additional items, interviews, and text along the way. The structure of each object’s exhibit is the same, which helps build comfort and allows users to anticipate how the other exhibits will be presented.

A more complicated exhibit, like America on the Move, offers a variety of ways for users to explore the content. A structured “Exhibit” gives users a chronologically-organized presentation of the content. The “Collection” is a typical archive of items that users can browse by keyword, search. The “Themes” section allows users to explore the content across time, thematically. Multiple options, multiple ways of “reading” the site, allows for more independence on the part of the user to explore how she/he feels.

Both approaches, however, depend on how the project team wants to present the content to the user, and where they want users to focus. Object of History has very specific goals: introduce uses to how historians can use material culture, provide narrative and related items to six key objects, and provide a place for users to try their hand at doing their own exhibits. America on the Move has more general goals: present and document the impact that movement and transportation has had on US history, and provide ways for users to explore that topic as they wish. Both approaches are valid and useful, but both are also reflected in the information architecture of the site.

Teaching Resources

With sites focused on teaching and learning we have a set target audience: teachers and students first, then the general public. As a result, the IA of the site reflects the needs of the primary audience. While some of the kinds of content may be similar, the manner in which site visitors go to access that content is different. Women and World History is an educational site that structures its site to emphasize the teaching resources it offers. Sections like “Teaching Case Studies,” “Primary Sources,” “Analyzing Evidence,” and “Modules” highlight how the site can help teachers to present the history women throughout the world in their classrooms. The titles of sections, the presentation of various content elements, all cater to the audience and the goals of the site.

Auditing and Displaying Information Architecture

Site Architecture Visualizations: Site Maps

I generally start thinking about site architecture with site maps, first sketched on paper or a whiteboard, then developed more formally with software like Omnigraffle or Illustrator. Dan Brown, in his book Communicating Design, rightly points out that site maps alone can simplify a web site too much, hiding the “spaghetti-like structure that’s really there.” Brown points out that site maps are a hold-over from a much simply time of web site development, when sites were simply static pages with little dynamic or database-driven interaction. (Brown) Still, I think site maps provide a useful method for visualization relationships among web pages on your site, and provide you with a map for potential avenues through which users can access your content.

Example site map using Garrett IA stencils in Omnigraffle.

When creating a site map you should strive to:

• Represent the virtual structure of a site with some simplicity.
• Represent relationships among sections/pages of a site
• Begin conversation for naming pages and sections (not concrete at this point)
• Explain why you think those relationships work for the site and for your audience

I use a tool called Omnigraffle to develop site maps and user interaction flowcharts. Omnigraffle comes preinstalled with the Garrett IA stencils—which I used in the example site map—and other stencil packages are available for download elsewhere.

Content Inventory: Spreadsheet

After getting a broader, general sense of the site architecture, its good to start a content inventory for each section and page of your site. This not only help to make the abstract site map more concrete, it also provides a communication tool between content managers and designers when building web pages. These are very helpful, for instance, for organizing and publishing complicated online exhibits that require lots of outside resources and displaying multiple files on a page.

Spreadsheets can be a quick and easy way to list information architecture. Using a spreadsheet can feel more like creating an “inventory” or “audit” of site content, but it can be useful for hierarchically organizing web pages, their descriptions, and a brief listing of their content. Content inventories are great because it gets you thinking about what content you want to display on each page, divorced from design.

Example of a content inventory from the online exhibit of Gulag: Soviet Forced Labor Camps and the Struggle for Freedom.

I used a content inventory when creating the NPS exhibit for Gulag a few years ago. With that project, our goal was to recreate an physical exhibit on the web. Thus, the physical exhibit already had set content and organization. The task, then, was to translate the display panels from the physical exhibit into distinct web pages, and make sure that the information displayed on each panel corresponded to the each respective web page. I typically use five main headings:

1. Section – The section title
2. Page – the title of the page
3. Location – The URL of the page
4. Description – A brief description of the page, how it fits with the section.
5. Contents – Number of paragraphs, word count, figures, images, video, audio, with specific file names to make finding easier.

Page Content Visualizations: Wireframes

A content inventory is very helpful when beginning the third part of site architecture: page wireframes. Page wireframes belong in the IA stage because they’re much less about design (layout, typography, color) and more about the importance of content pieces relative to each other. Additionally, they function as blueprint for what specific content areas should be on each page. It is extremely difficult to design a web page, or code a web page, if you do not know what the site architecture is as a whole and what content will go on the page. Creating and discussing wireframes in the IA stage not only help anticipate specific content pieces for each page, they also help you evaluate how your site organization is represented on individual pages.

Remember, the goal for wireframes is to discuss relative importance of content on a page—what should be important, not how to make it important.

When discussing wireframes, try to steer the conversation away from the design aesthetics of the wireframe and more towards the content delivery of the wireframe. What content does it emphasize? What content does it reduce in importance? Should one piece of content appear more important than others? Is all the content represented on the page? Avoid conversations like “The navigation needs to be on the right,” or “The font should be Georgia” in favor of observations like “I think the callouts should be emphasized more than the secondary navigation,” or “The item’s title should be equally important to the items subheadings,” Remember, the goal for wireframes is to discuss relative importance of content on a page—what should be important, not how to make it important. There’s plenty of time for how conversations in the design phase. Discussing what goes on the page, and how each page component related to the others, will give the designers good ideas to do their jobs: design.

I recommend creating three levels of wireframes: homepage, browse page, show page. Your mileage may vary, depending on your content and type of site, but its good to think about how content is presented differently at different levels of your site. I also use Omnigraffle to draw page wireframes, using a stencil package by Michael Angeles, but I’ve also done wireframes on whiteboards, and with pencil and paper. In fact, I would encourage you to start with pencil and paper before creating a more formal wireframe in Omnigraffle.

Content Delivery

All the planning for information architecture will pretty much go to waste if that content isn’t delivered in a timely fashion. Luke Wroblewski suggests visualizing a “content delivery schedule” to keep the development and delivery of content on time. Using a simple calendar or table, you could construct a list of specific pages or sections of content that needs to be delivered, when it’s due, and who’s responsible for delivering it. An simple example using a table:

You could just as easily use a spreadsheet, Google Calendar, milestones in Basecamp, or a wiki page, but the end goals are the same: have deadlines for content delivery and know who should be delivering content.

Importance of Information Architecture

Here are a few concluding points/summaries about why content management and information architecture are vital:

• Thinking about content organization gets you thinking more about what kind of site you want to build, who you want to use this site, and how you can best cater to that audience
• Genres of sites impact information architecture.
• Scope creep with content—involving both removing content and adding new content—affects decisions in future design/development phases.
• Begin thinking more abstractly about site architecture (site maps) and end with more concrete thoughts (page wireframes)
• Be sure that all the steps you take in developing site architecture coincide with the project requirements you set at the very beginning. All work in this phase must ensure the requirements are met.

Once the team has agreed upon the architecture and organization of a site’s content, designers can begin working on, you guessed it, design! In the next post I’ll discuss the process for coming up with a design for your project!

I would advise that in this phase, you try to answer the following:

• What is the site?
• What content will be on the site?
• Who is the audience? How will we want them to use the site? How will they use the site in other ways?
• What specific components are needed on the site? What technologies? Static HTML? Need dynamic content? Need a CMS? Need a custom web application or interactive features?
• What is the timeframe for completing specific phases of the project? What is the timeframe for completing the entire project? What other projects are vying for time?
• Who is on the project team? What are their responsibilities? How much of their time do we have, or can get?

Questions

What is the site?

If you can’t answer this, it will be very difficult for everyone on the team to actually build it. Its OK for the definition or description of the site to evolve over time. In fact, you should probably expect this, as your user base grows or you get new content. The project team does need to hash out, in a paragraph or two, what exactly the site is about, what it offers that other sites do not, and why it is important. If you can’t justify building the project, you should consider whether you should build it at all.

What content will be on the site?

It is very helpful to everyone on the team to have a discusion of what kinds of content will be on the site. This isn’t saying that the content needs to be done at this point; only that a good idea about what content and how much will be on the site. Is is primarily images? Text? Video? Some combination thereof? Is the content something the team is preparing, or something collected from the public? Is it a “web translation” of a physical exhibit or a book? Is it web-native? The kinds of content, its origins, and the expected interaction between users and the content, will influence answers about who the target audience is and what technologies are needed for the site.

Who is the audience?

The answer to this question has important consequences for the development of the site. Even if you have a solid answer for what the site is, and what content will be on the site, the audience for your site greatly affection how you present that content on the site. A teaching site on the history of the Spanish-American war may look and be organized differently if the primary audience is elementary or high school students instead of teachers. The language used on the site, the content for the site, and the design are all affected by the target audiences.

Needed technologies?

From the very beginning, before one line of code is written or one pixel moved in Photoshop, the team needs to decide what kinds of technologies will be needed for the website. Answers to this question depend on answers regarding what the site is about.

Do not have a “feature-centric” mindset when discussing options for a project. Think about what your want the site to accomplish, and then decide what technologies will best help and why they will help.

The development team specifically needs to help answer this question. Following Tom Watson’s advice, the project team should come together to discuss problems to solve, and what technologies will best solve those problems. You do not, for example, need to use a robust content management system like Drupal if your project consists of only a dozen static HTML pages.You do not need AJAX simply becuase other sites have AJAX; You do not need a blog because other sites have a blog. In other words, do not have a “feature-centric” mindset when discussing options for a project. Think about what your want the site to accomplish, and then decide what technologies will best help and why they will help. Have a reason for everything!

I would say that the development team needs to be the lead on answering this question. They will (or should) have the most experience with determining which technologies will solve specific problems. But its generally good to talk about the problems first, so the development team can decide on which techology solution will best solve those problems.

Timeframes?

All of the previous answers can be fantastic and full of possibility until you talk about the most important aspect of a project: time. Time can be a harsh master. It is a very a good idea to set deadlines and milestones, to keep the project moving forward and give everyone a sense of how long things will take and when they’ll be done. In some cases, work by each team member can continue simultaneously. In others, one team member must complete a requirement before another team member can start or finish her/his requirements.

In some cases, deadlines are set by grants: “We promised a fully-function site to collect public reflections by May 2009,” for example. Those absolutely should be met. Others can be a little more flexible, but not so flexible that the project never gets finished. Here’s a quick process for setting milestones and criteria:

1. Figure out what milestones are needed (content complete, CMS installed, wireframes completed, etc)
2. Set deadlines for each milestone, for specific phases of the project
3. Associate specific criteria for completing milestones by the deadline
4. If those requirements aren’t met, decide whether to move the deadline for the milestone up to allow for completing the criteria or to remove specific criteria as unnecessary.

In other words, deadlines should be stable enough to provide direction and purpose for the team, but flexible enough to account for unexpected contingencies. If you’ve reached the deadline for a milestone, but do not have all the criteria done for the milestone, consider whether those criteria are necessary to move on. Its OK to say that some criteria are, in the end, unnecessary to consider a milestone complete, and to move those criteria to other milestones and deadlines.

Having milestones, set criteria for meeting those milestones, and deadlines for milestones help keep the project on track, and prevent “feature-creep” or “scope-creep.” By this I mean the tendency for a project to take on new features or new scopes that were not set in the beginning of the process, and cause deadlines to be missed. Its fine to add new features, or change the scope of the project, so long as everyone on the team understands that the timeframe and deadlines may have to shift because of those new requirements.

Team Members

Everyone on the team should be introduced to each other, with a brief discussion of each person’s specific skills and responsibilities for the project. This not only helps build camaraderie, it also lets someone know who to contact for specific questions or issues. Having trouble finding or using the project logo? Ask the designer. Having a problem with a specific aspect of the CMS? Ask a developer. Not sure where the content is for a specific section? As a content lead or project manager.

Management Hubs

This is a lot of information to manage, a lot of tasks to track, and a lot of people to potentially know and talk to. You shouldn’t even try to manage it all on paper, or in your head. The project team needs a central location to go retrieve information about the project, manage tasks, and learn more about other phases of the project. In comes a management hub.

Screenshot of CHNM Basecamp page.

At CHNM, we use Basecamp, a service created and offered by 37 signals. We manage dozens of projects on our Basecamp account, with each project having a homepage, Messages, To-Dos, Milestones, Writeboards, and a place for file uploads. There is a list of everyone involved with the project, with roles and contact information. You can associate a specific to-do list to a milestone, and can thus determine if you can “complete” a milestone if you have completed all the tasks in the associated to-do list. You can assign to-dos to a specific person. We use Writeboards for meeting agendas, notes, and any other documentation we want to keep (styleguides, ideas, etc), and we tend to use the Messages feature more than email to send correspondence concerning a project, that way everyone has an archived copy of the message in Basecamp. As CHNM has grown, Basecamp has become indispensable for managing all our projects.

Alternatively, you could easily use a wiki to manage your projects in much the same way as Basecamp. Free wiki services abound on the web (PBWiki is great, for instance). While not as feature-rich as Basecamp, wikis can fulfill all the needs for project management, with a little work and devotion to organization. You could set up a PBWiki with the following pages:

• Homepage—The “dashboard” with the description of the project, the goals for a project, and list of team members with responsibilities. Links to other sections:Timeframe, To-Dos, and Notes.
• To-Dos—divided by person or aspect of a project, marked off as they’re completed.
• Notes—any meeting notes, archived discussions, or ideas you want to archive.
• Timeframe—a running list of milestones, with criteria listed for successful completion of each milestone.

In any case, the hubs should at least contain the following:

Description of the project

A paragraph or two stating what the purpose of the project is, what it encompasses, who its target audience is, and what the site will offer.

Goals for the project

A well-defined list of goals or deliverables for the successful completion of the project. This helps keep everyone on target, and ensures that any decisions made during the development of a project should only contribute to, and not add or detract from, the goals.

Project team members

I recommend devoting an entire page, or section on the main page, for listing team members, with their roles or list of primary responsibilities listed and contact information. Perhaps even a link to personal webpages or profiles.

Timeframe

Deadlines, criteria for completion of the project, and major milestones.

To-Do lists

Pretty straight-forward: lists of things that need to get done for a project. This can be divided by person, by team (design team, development team, content team) or by sections of the site. its helpful to have these in once place, so that everyone on the project has a sense of the amount of work everyone is facing. Good especially if someone asks for new features not part of the original description or goals for the project.

Meeting notes, various content pages, links as needed

Good to keep in one central location for all team members to contribute to and refer to throughout the project.

You should totally feel free to set up a wiki however you want, but you goals should be: keep everyone informed, archive project progress, and keep the scope of the project clear and visible.

All Alone?

If you’re your own project manager, have this meeting with yourself. Before you type one line of code or color one pixel in Photoshop, go through this process. Set up a project hub. Take meeting notes. Create a timetable. Make to-dos. Some of it may be meaningless (like list of team members), but it helps to formalize the development of a project. And, if you end up getting a grant or someone volunteers to help you with the project, you’ll easily be able to orient them and integrate them into the workflow for the project. If it helps, have someone else around to talk through ideas and get things down more concretely, or pretend you’re explaining the project to someone else.

What’s Next?

After doing all of this, either in one meeting or several, you should be set to move into the next phase of development: Information Architecture. I’ll cover this next week!

1. 1 See Kelly Goto and Emily Cotler, Web ReDesign 2.0: Workflow that Works, Berkeley, CA: Peachpit Press, 2005, 40.
2. 2 Jesse James Garrett, The Elements of User Experience: User-Centered Design for the Web, New York: AIGA and New Riders, 2003, 23.

The Series

Part One: Figure Out What You’re Building

Figure out what exactly you’re building. Seems simple enough. Meeting with project managers and content creators about what exactly we’re doing, what kind of site we’re building, is of the utmost importance at the beginning of a project. This post will address some basic questions to answer when first starting a project, establishing responsibilities, and setting a timetable that works for everyone.

Part Two: Information Organization and Architecture

Get organized. Before you touch a line of code or a pixel, figure out what the information architecture of a site is. A lot of people fail to realize that the structure and organization of content greatly affects the design and development of a site. Here we’ll take a look at some useful techniques for working out how the information is organized throughout a site and on specific pages.

Part Three: Design Process

Create meaningful design solutions. Now that we have a stable information architecture, its time to put that information into a useful, meaningful design. The important thing to remember here is that design is about solving problems and addressing specific issues. Its not about your favorite color or font; its how all the design elements (color, typography, space, layout) work in concert to provide users with a meaningful web experience that we defined in previous steps. Here we’ll discuss how to start brainstorming for design ideas, how to bring those ideas into tangible results backed by a concept, and how to present and discuss those results with the project team to get productive feedback.

Part Four: Front-End Development

From pictures to code. OK, so we have a design concept that everyone on the project team has approved. Now we need to take those mockups and translate them into working web pages, and eventually apply them to the entire site. In this post, we’ll take a look at how to go from those image-based mockups to HTML mockups to a full-scale working website.

Part Five: Going Live, Maintenance, Documentation

Launch and post-launch tasks. When you take the site live, your work is still not done. The site will need to be maintained, content may need to be added, and user concerns will certainly need to be addressed. Here I briefly discuss the steps to make a site live, elaborate on points concerning maintenance of a website, and provide ways to document the websites to better facilitate that maintenance.

Fluidity

These aren’t discreet “steps” in that one must be finished before work on the other can begin. This kind of process would be very impractical. Instead, I like the approach Jesse James Garrett takes in his The Elements of User Experience. Garrett argues that work on each step should finish before work on the next can finish. So, for example, establishing the information architecture can’t be completely finished until you’ve finished figuring out what exactly you’re building.1 Work on all steps continues well into the next, but changes in one step can mean that the team has to revisit previous steps. This approach provides a much more fluid, flexible work process, but also requires lots of dependencies and clear communication among all involved.

Any code or files I use will be included with each article for download. I really hope you find the series useful. Check back next week for Part One: Figuring it Out.

1. 1 Jesse James Garrett, The Elements of User Experience: User-Centered Design for the Web, New York: AIGA and New Riders, 2003, 27.