Information architecture is not optional. And in a perfect world we’d all have adequate time for a formalized, thorough information architecture evaluation process at the beginning of each SharePoint solution cycle. But what if you have limited resources and need to provide a quick–yet effective–information architecture review? What are the essential steps you should be taking? This blog post summarizes my quick and easy information architecture/storyboarding methodology. It may take a bit of work to tweak this for your environment and shorten up the evaluation steps, but the framework should give you a good starting point. Enjoy!

We hold these truths to NOT be self-evident…

Before we begin, a couple of universal user truths:

1. Users (even the well-intentioned ones) will generally take the path of least resistance. They will create content and take the time to store it, but will often opt for familiar folder storage structures. While these structures make sense to the content creator, they are often difficult for others to navigate.
2. Users will be interested in functionality that can improve their lives. But they often won’t have the time to investigate this functionality on their own. They need information architects and designers to paint the vision. Often I throw out 15 ideas for each individual idea my business users choose to implement. There’s nothing wrong with a 15:1 ratio. The key is to keep offering ideas that will maximize user opportunities. Even if they don’t implement your ideas right away, they will likely circle back to consider some of the ideas again later.
3. If information architecture is optional, users will opt out. You need a carrot and a stick to get their attention. If you can offer SharePoint planning services free of charge and have a good reputation for delivering top-notch solutions, that will be all the “carrot” you need. If you can require team members to work with you in order to have a SharePoint site or site collection created, you have your “stick.” Again, if this model doesn’t work in  your organization you’ll need to improvise. Just remember to include both the carrot and the stick.

The storyboarding process

I log my projects against the following SharePoint lifecycle stages:

• Stage 1 (Initial request received)
• Stage 2 (Storyboarding in process)
• Stage 3 (Site/function development)
• Stage 4 (Iterative review)
• Stage 5 (Launched)
• On hold (Waiting on business requestor; funding deferred)

Most of these stages are self-evident. Stage 1 begins when a SharePoint request is received. These can be requests for a new SharePoint site or enhancement requests for an existing site. Both “new” and “enhancement” requests follow the same storyboarding process.

First, I set up some one-on-one time with the business requestor. Since I work in the same geographical location as my customers, I have the luxury of setting up in-person meetings. Here’s the agenda I follow for these initial storyboarding meetings:

1. Introduce my role and explain our SharePoint methodology. This gives me an opportunity to explain how the “carrot and stick” works in my department while also enabling me to explain how our SharePoint site collections are structured.
2. Ask about their “vision” for the future. This question is intentionally vague. It is intended as a baseline, and won’t be the final vision statement for your SharePoint design. Usually, users will answer this question with a general statement saying they “want a site like Jane Doe has.” There’s nothing wrong with a broad answer here. Capture whatever the customer says and move on to the next step.
3. Ask what the business need(s) are they are trying to solve. In some cases, users will already have their scope defined. Generally, though, users are confused by this question. Again, don’t worry about a lack of detail in their answer. Capture the response and move on to the next step.
4. Get details on the current work process, including highlights, pain points and bottlenecks. Here’s where the deluge starts. Many users may have difficulty outlining a scope or vision for SharePoint, but most can wax poetic on pain points and bottlenecks in their common work processes. Encourage them to whiteboard their current pain points and allow them to dive into details. You’ll want to capture the broad strokes of this content and along the way identify opportunities where SharePoint can provide key wins. I try to capture several types of information during this step:
• Key steps in the current process that can be automated using SharePoint.
• Key pain points and bottlenecks. These will turn into the critical success factors for the future SharePoint solution.
• “Soul crushing” work that can be eliminated or automated. These are the wins that will act as change management agents. Eliminate work that everyone hates and you’ll automatically build support for SharePoint
• A rough percentage of time that can be shaved off the existing work process. This will help me capture a SWAG return on investment (ROI) for this solution.
5. Get a wish list of things they dream about. Tell them to think big and ask for the world on a stick. Don’t worry about keeping them “in scope”–just capture their answers. (Note that at this point many users won’t have any idea what SharePoint can do so their wish list may shoot too high or too low. Don’t sweat these details.)
6. Provide a demo of “similar” functionality already launched. At this point, I have a fairly good idea of the pain points and potential SharePoint solutions that could be built. Now it’s time to give the business requestors some idea of the possibilities. I provide a 15-minute targeted demo of existing SharePoint sites/functions that most closely align with their potential needs. For example, if the customer is in dire need of an optimized issue-tracking solution I’ll demo issue trackers with automated email and reporting that are already in use by other teams. If the customer needs help with document retrieval, I’ll demo a content type-based metadata tagging scheme that enables easy document upload/tagging.The key is to demo live sites that are already in use and have granularity levels or functions that mirror what the new customer needs. If you don’t have any existing SharePoint sites that apply, take them on a survey course of SharePoint wins you’ve already delivered for other teams. If this is your first SharePoint project and you don’t have any production sites to demo, start drawing out possible solutions on a whiteboard.The objective is to “blow the lid off” the customer’s expectations and get them “thinking big” about what SharePoint can do. You’ll know you’re hitting the right note when users start getting visibly excited and start tossing out additional ideas for how SharePoint can help optimize their business. Encourage them to brainstorm–the more ideas on the table the better!
7. Connect them with business owners that are already on their way. You are not objective. Clearly you are enthralled with SharePoint and have a vested interest in its success at your organization. In order to give your customers a fair (unbiased) view, recommend they touch base with other business owners that have already implemented SharePoint solutions. When these other business owners recommend SharePoint (and you), your customers will be doubly impressed.
8. Revisit the goals and wish list. Before you close out your meeting, revisit steps 3 and 5 to see what your customers updated goals and wish list items are. By this point, your customers should have a much broader list of features and functions they want to deploy. Capture as much of this information as you can. You’ll have the chance to map these goals and wish list items into project implementation phases at a later point in time.

Note that the timing for each of these eight steps is fluid. Depending on the size and scope of your project you may need to allocate 2 hours, 4 hours or even a full working day to get through all these steps. Over time I’ve been able to wean these steps down to a 1-2 hour meeting for small projects (aka projects that result in a 4-40 hour development effort). As the size of the implementation expands so will the amount of design time that is needed.

Also be aware that you may need to schedule follow-up meetings to dive deeper into one or more of these eight steps. Be targeted about these follow-up meetings. The key is to take up as little time as possible for information architecture. If we make the architecture process too painful, users will opt out and you will lose a SharePoint deployment opportunity. 

Once you have enough raw material gathered, start designing your SharePoint vision for success. Tailor your vision to your audience. If your customer is informal and buys into your vision readily, you may be able to meet with them in person and present your vision for the future using whiteboard diagrams. If your customer is more formal or requires executive sign-off, you will need to create wireframes. Consider using Balsamiq (http://www.balsamiq.com/) or another quick wireframing tool to illustrate your vision. The key is to effectively illustrate your vision without taking the time to build out a robust system before gaining customer approval.

Once your requirements are documented and you get management sign-off you are ready to build out the solution!