Information Architecture

Design Action Collective

• graphic design & web studio serving social justice organizations
• based in Oakland
• worker-owned cooperative, union shop
• 11 worker-owners
• been around for 12 years
• two departments: print & identity design, web development (mostly WordPress)
• folks tend to share information architecture work and project management

Information Architecture: three phases of DA's process

• Discovery process
• Creation of a site map
• Creation of wireframes
  • Blueprints for the house
• Goal: be really thorough in that part of the planning so that everything is well laid out, the developers can start building the site as the designers start working on the visual design; answer questions up front, save time and headaches down the road
• Work with clients with really small budgets; help them define the scope well, have a reference for when there's scope creep

Discovery

• Look at the overall goals of the organization to determine what they want to tell people with their website; how they want to invite people to join and support the work; who the users of the site will be.
• Lots of the same questions are asked for logo/identity development and working on info architecture: who are you? who are your users, why are they coming, what do you want to tell the world about you? Have those as centering questions throughout the process.
• Who are the users: mix of members, donors, general public, press, etc; determine what information you want each of those groups to access.
• What do you want brand new visitors to find out about the org at a glance? How do you greet people?
• What depth of information does each of the different audiences need?
• Are they looking at information from the past (past campaigns & work?), events, current campaigns? Are they looking for outcomes of work (esp funders)?
• What do you want to show the members of the organization? Do they need registration forms, etc?
• Case study: First Place for Youth:
  • Appeal to older donors and younger donors
  • There's a lot of overlap between what different audiences want to see, but they might also each have specific needs

Site map

• Draw a diagram; pinpoint topic areas; organize content thematically and for each of the audiences
• Used Fireworks to draw the diagram
• Shows relationship and proximity between site content; show you how to rearrange and change things
• Spreadsheets can also be useful: space for defining what each piece of content should do. But the diagram lets you show how content is interrelated.
• Identify all of the things you want to show, then determine how much you need to show of each of those things. E.g. funders want to see your past work, but don't need to bog them down with countless PDFs to download from your website to read.
• Coming up with the site map involves a lot of work both from the organization and Design Action.
• Lots of times DA isn't involved in those internal organizational meetings; they ask a central contact to synthesize the feedback from the organization. DA gives folks a questionnaire, asks the client to make sure that everyone who needs to give input gives it during that phase, to avoid the pitfalls of what can happen in an internal process. Give guidance on what to discuss, consolidate everything down, come to agreements internally, then bring that back to DA.
• Sometimes they guide clients through the process without actually facilitating those internal meetings.
• Discussing more and more about accessing existing analytics for an existing site you're redoing. What's your most popular content on the site? Don't want to move the stuff people access all the time. If there's something important on your site that people aren't ever accessing, how do you change the position so that it's more accessible?
• At the end of the site mapping process, ask clients to commit to the final product; clients sign off on it as the final site structure because the rest of the process builds off of it. If the client decide to make changes to the site map down the road, it will require stepping back, expanding the scope, increasing budgets.
• Question: how do you navigate the hefty amount of discovery and site mapping when dealing with the client after they've hired you based on an original budget estimate?
  • Try doing some of the discovery before providing the estimates, e.g. through the questionnaire.
  • Depending on the organization and their budget, they might not let them write things into the site map that will take it over the original estimated budget, OR flag that they're likely to reestimate after the information architecture phase.
  • Phases are another approach; here's what you can afford now, here's what we can do later.
  • Provide rough estimates first, but then as the info and details emerge
  • Openflows: do a discovery phase in a separate work agreement, try to avoid doing estimates before doing the discovery period.
  • Do an itemized list of functionality with individual estimates to help clients prioritize what's needed.
• Internal processes at organizations can be really heavy; a lot of cooks in the kitchen, a lot of back and forth. Having a point of contact in the organization needs to communicate effectively to the vendors, keep people internally on track. Can take months to get through wireframes internally.
• The site map phase is where you determine what sort of functionality is needed for each section of the site, what's needed for each component. Ask leading questions to figure out those details of what functionality is needed, e.g. do you really need an event manager if
• Question: how do you manage scope creep, help people understand how things are adding up throughout the project?
  • For each deliverable, give the client guidance on what to focus on there, the important questions to answer there.
  • Can be difficult to be the internal point person for a project; it's important to make the client's project manager part of the development team in a way; be an ally with that person; have really open communication.
  • Project management system with thorough documentation of decisions and how we came to them
  • Time tracking within that project management system to map scope creep to
  • QA time for the changes that come down the road.
  • Give people admin training so that they can make some of the little changes and tweaks (especially around textual elements) themselves.
• Question: how do you talk to people about pages vs posts?
  • What's current/changing frequently and what's more static?
  • Show people examples of the differences between a static page vs an automated flow of content.
  • A little bit more complicated when it comes to custom post types with custom fields.

Wireframes

• After the site map sign off, they know the general pieces of content on the site; next is wireframes, the blueprint of each page on the site, the placement of each piece of content on the page, prioritization of content.
• Make a list of all of the different types of content on the site; what are the types of content that are highest priority on the site based on discovery?
• Start with the homepage (usually the desktop view, sometimes the mobile view.) Create three options for the homepage with different pieces of content being highlighted in different ways. Send those options to the client as a place to start the conversation about how the homepage might be structured.
• Give the client the different options in Basecamp, give a cover letter explaining the wireframing process: "Our goal with this phase is to log in the wireframe, a visual document used to plan the website's page structure...wireframes don't show any design elements, only information hierarchy/placement/prioritization on the page. Focus on what content we're featuring and where it goes on the page. Consider how the audience is using the website, what's the most important info they need to see, how to keep visitors moving towards your goals. After finalizing the wireframe we can sketch out more of the design and aesthetics. Choose one of the options as is, provide feedback to improve one, or request completely different."
• Questions:
  • Do the menus move rather than confuse?
  • Does primary content work? Does secondary content naturally flow?
  • Does the structure of content move people to your goals? etc etc.
• Will usually get feedback that mixes and matches different wireframes; useful to get and easy to incorporate the different feedback.
• Once they've landed on a solid option that the client is happy with, go through the wireframe process for tablet and phone.
• After that signoff, goes through a process for interior pages; depth of that internal page wireframing process depends on the client and their resources.

And beyond...

• After those are done, the developers build a "click-through wireframe," building the site out without any design; the designers start doing the work at the same time. Content population can start happening at the same time as the visual design; once that's done, start skinning the site (converting the approved design into a theme.)
• Design process: also present three very different designs for the client to review.

Q&A

• Good rules for when to use sliders and carousels and when not to?
  • Vastly different opinions on this!
  • Only time to use a slider is when it's going to drive traffic to a specific goal. No just rotating pictures for pretty pictures' sake; highlight important content.
  • A slide should be a very clear ask for someone to do something.
  • People want them no matter what! Where's the level of pushback that's appropriate? But make the first one the best/most important one.
  • Can be a usability nightmare!
  • If you can present analytics/facts to support whether or not to pursue an option, that can be really helpful.
  • Rare to have a ton of really nice images!
  • With a big budget, argument for building and launching a site, months later doing a thorough review of the analytics to see if goals are being met, then redoing/retweaking it.
  • Every audience for every website is different, so having the ability to set goals, do the work, do the analysis and then
• How much time do you usually allot for these things?
  • Discovery: 3-4 hours, site maps: 3-4 hours, wireframes: 3-4 hours. 12-14 hours total.
• Design and content entry in parallel: do you ever find that content conflicts with design?
  • Yes!
  • Stressing that changing things at that point winds up increasing the budget of the project; that staves a lot of those changes off.