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:
- 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.
- 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.
- 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:
- 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.
- 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.
- 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.
- 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.
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!
Thanks for the overview, we are just starting to develop processes and training for SP Analyst and you observations have provided needed insight.
Once again, Sarah Haase takes a complicated-overwhelming topic and reduces it to usable chunks people can start using now.
Reblogged this on links and commented:
Thoroughly enjoyed this logical approach to “light” project management with internal customers new to the opportunities in SharePoint solutions.
I love it, perfectly succint!
Sarah, can you expand on Information Architecture?
Information architecture is a large continuum, and no two information architects are likely to agree on a definition of what it is. My point of view is this: information architecture is the science of examining/structuring content for optimal intake, storage and retrieval. The type of content involved varies wildly–you could be designing knowledge management systems with formal taxonomies, inventory control systems with product metadata or Intranet/Internet sites with corresponding content publishing. The key is to analyze the types of content you have and determine what management needs you have regarding that content.
For more on this topic, I recommend Ruven Gotz’s book Practical SharePoint 2010 Information Architecture. It is an amazing read.