Strategies For Information Gathering--Your Take
January 03, 2005 | 
12 Comments
It’s been a crazy few months for me, trying to get situated at my new job. I’ve still got a way to go as it’s a bit different than what I’m used to and I’m being asked to take on roles that are unfamiliar to me. But, hey, I’m still building Web sites and that is something I know quite a bit about.
One of my primary roles concerns our process. I’ve worked with many different Web design processes over the years, and none of them are perfect. The good thing is that there was a pretty solid process in place when I started and the we have the talent, energy and know-how to do really, really great work.
(Some of which I hope y’all will be seeing soon.)
One of the areas in which I and my coworkers can see room for improvement is with information gathering. I’ve been spending the last few weeks thinking about this and talking to colleagues of mine to get an idea about best practices for information gathering. I’m not ready to talk about my findings, but I thought I’d put some feelers out and see if my readers had any ideas or experiences to share.
(I’m trying to learn about information gathering by, what else? Information gathering.)
Before we get to that, it might be best to define what kind of information gathering I mean, where I see the need for best practices, and what some of our challenges are.
Information Gathering & The Web Design Process
There are several points during the Web design process that call for information gathering. In general these tend to be at the beginning of a project. I see a typical Web design project could have the following components:
- Scope Assessment
- Information Design & IA
- Content Development
- Visual Design
- Code Design
- User Testing
- Production
Those aren’t necessarily in order, and they’re just an example of the kinds of things that go into a Web project. As you might know there could be other things, and some of those things may not be there. I’m learning quickly that what people will pay for and what should be done in a Web process aren’t always the same thing.
Where information gathering comes into play is when you need to have information, big surprise, to create an estimate or plan, in order to move the process forward, or inform design. Not having the proper, or complete information, can stall a project or worse.
Some Specifics
In talking to various people about this I’ve found that it’s pretty common to go into a project under-informed. As well, it’s pretty common for Web projects to end up out of scope, late and over budget. There also seems to be a bit too strong of a focus, especially by information design folks, on deliverables. In general, we should be gathering information (and using the corresponding deliverable) to inform, not to produce a document for its sake alone or placate a stakeholder, although we do these things as well and they are important in their own right.
The kind of techniques I’m looking for are specifically those that help to inform design decisions or planning. I’m particularly interested in hearing what’s worked for folks when it comes to the gathering of information to inform:
- An estimate or pre-project scope (this is a big one)
- What I’m calling a Content Brief (think technical brief or creative brief focused on content)
- Personas, User Scenarios or Customer Profiles, which in turn inform design decisions (user research)
- Content outlines to facilitate the creation of wire-frames and a site map, which inform design decisions
If you’ve got some good experiences to share, I’d love to see the comments here to benefit others. I’m really interested in techniques that are efficient—low cost, easy to implement and effective. I want things that ultimately save time and help us work smarter, not just bloat the process.
Filed under: Web General
Comments
1. Wade Winningham said:
One of the most valuable tools I’ve found in building websites is to create a Risk Assessment document and keep it up-to-date on a weekly basis. I started this after getting into the Microsoft Solutions Framework which covers most of what you’re asking about.
By documenting the top 10 risks for completing the project and distributing it, people generally react like you lit a fire under their butts. Some of it’s because you’re stating emergency items that need to be dealt with. Some because you may be assigning a risk’s resolution to someone specific and putting a spotlight on them. It helps you focus on the most important things without becoming overwhelmed by everything.
Posted on January 3, 2005 07:55 PM | #
2. Chris Vincent said:
You have the initial information gathering, and then you have the constant communication that goes on throughout the project. For the latter, I recommend using Basecamp to manage the project. In the past, Basecamp has been a great tool for me when working with clients and colleagues.
I guess I’m not suggesting a process so much as a tool, but it’s a tool that can really facilitate that process well.
Posted on January 3, 2005 09:41 PM | #
3. Keith said:
Wade – Thanks for the tips. Sounds like good advice.
Chris – We use Basecamp. We love it and yes it’s a great tool. We’re still working on how best to use it, and expanding it beyone Web team use a bit more, but I’ve got to say it’s been, really helpful to me as someone new to the company and people’s ways of working.
Posted on January 3, 2005 10:19 PM | #
4. Luke Barton said:
A few things that might help inform your budgeting and project management decisions. These not only guide pre-project decisions, but provide a framework through which to revise esimates, timelines and scope.
1. Stakeholder interviews. I find that if a client or a team member plays “gatekeeper” the whole time, projects end up misinformed because only one perspective informed the decisions. If everyone can get in on the interviews early – or at least read the transcript or notes – then more rounded solutions naturally come up. (Oh yeah, the interviews need to be cross-disciplined as much as possible.)
2. Walk arounds. If it’s possible to walk around a client’s office to do interviews that helps. It keeps things casual and you can stumble into actual users. I did some work for a hospital once and walking around helped immensely. Or, imagine shadowing a client’s user for 1-2 hours in their own environment. You can offer people small incentives to allow that – coupons, vouchers, 100 bucks – it’s almost always worth it.
3. Zoomerang surveys . There free, quick and easy to use through email.
4. Competitive website reviews. Spending a few hours on competitors’ websites and then showing that to the client can help – “hey, we would never have thought of that.” Then you have an exact target, which you try to copy, improve and conquer. Targets like that save time and offer concrete, scope-able items.
5. “Pretend Interviews.” Some situations lend themselves to your pretending to be a customer and calling the customer service hotline – of your client or of a client’s competitor. That way, if you’re designing around a process, you can be a part of the process like a real user. Substitute “calling” with whatever fits your project – ordering online, going to a story, completing a registration, attending a conference, etc.
6. “Best Practice Collections.” If you keep an archive or a “toolbox” of best practices, you can build on those to save time and create better estimates.
7. Did anyone mention usability tests? 4-5 people can give you tons of information; 6-10 people convince vice-presidents that they might be wrong after all.
8. General info dumps – “give me all of your marketing collateral from the past 3 years.” Sifting as a 3rd party objective view helps. A lot of time the “right answer” is buried in there, and the client is just dancing around it the whole time.
All of this due diligence may allow you to re-assess the budget, timeline and scope with the client. If you do enough research and present it well, it can convince the client that you are of sound mind and are correct in your re-estimate.
Then you might even find more work…
Good luck with your new job.
Posted on January 3, 2005 10:56 PM | #
5. Mike Cooper said:
I just took on a huge web overhaul process with my employer. The current website is so outdated (circa 1993) that it actually needs to be built from the ground up. Are company is divided into “functional” teams instead of departments as part of an ISO standard, but it works. Here’s some of the stuff we did:
1. Brainstorming session with team leaders. The goal was to gather as much information from them as possible without them knowing exactly what we were looking for. In a brainstorming session be as vague as possible and keep people talking. You can gather a lot of information in a short amount of time. Don’t let them talk specifics of their area, but rather the organization as a whole. From here you can define the general scope of the project.
2. From that information, start looking at scope specifics. If you have existing work, where does it all fit into place? If it’s all new, with the ideas expressed in the brainstorming session what was emphasized by more than one person. People tend to say the same thing in many different ways. Create an information matrix. Where would you group information.
3. Meet with individual functional teams. We had a list of six questions. Make sure that they know you are not asking these of the website specifically, but in general everyday work. It’s the web teams responsibility to decide what can and can’t be done on the web. There’s things that individuals do that can be converted to a web-based process, the only thing is that the individual doesn’t realize that it can happen. The six questions were:
Who are your customers?
What do you currently provide each of these customers?
How do your customers benefit from what you provide?
How does the organization benefit from what you provide your customers?
What do you want your customers to do (customer actions)?
Do other departments benefit from what you do? Could they?
What are your plans for future growth?
If you were to create a new web site, what would you like to see? (Wish List, complete pie in the sky view).
3. Analyze, Analyze, Analyze. From the information gathered, you can start to see patterns form, specifically in IA. You can see which departments interact with each other, and departments that provide the same information. You can now refine your information matrix to better serve the organization. And, once you have your information matrix, you pretty much can start establishing the project as a whole.
4. Develop a Work Breakdown Structure. I follow the Systems Development Life Cycle for high level tasks and work down from there. Don’t get too specific, but be specific enough that you can reasonably estimate timeframes.
5. Now you have your WBS. Estimate the timeframe for each step. Seems simple enough, but remember to calculate in hours, not days. Use a shorter work day than 8 hours. Other things that require your attention come up, so you can’t expect to devote 8 hours a day or more to a project. Also, work in some time for risk assesment. There are risks to every project. The biggest risk is losing a project team member. How long will it take to bring someone else and catch them up to speed?
6. Create a budget from your timeline. Based on the hours people are working on tasks, what are the estimated costs? Is there other materials that will be required (software, hardware, etc). Work those into the budget as well. The thing to remember on budgets, is a 3:1 ratio of ROI to cost. If you do it right, a new website will easily hit that 3:1 ratio.
Number 1 rule of thumb in Project Management:
It’s the plane that you don’t see that will kill you.
Hope this helps.
Posted on January 4, 2005 07:19 AM | #
6. Keith said:
Luke & Mike – Thanks for the input! Good stuff. We do use some of the techniques you mention, but I did find a few interesting nuggets in there.
It’s funny, when reading this stuff, and it talking to other folks about this, I realize that we all have very similar challenges, and the stuff you deal with as an outside consultant isn’t that much different than when your internal. You just have a different perspective–and are perceived differently.
Posted on January 4, 2005 08:40 AM | #
7. Krista said:
You might try reading Web Redesign 2.0: Workflow that Works by Kelly Goto and Emily Cotler. I’m about 2/3 through the book for the DWM review. One of the key strengths it offers is how to formalize and organize client communication from discovery on. Even scanning the table of contents, I was thrilled to see ideas and tools I could implement immediately. The companion website http://www.web-redesign.com is an excellent resource and has sample client surveys/communication briefs for download. The book is well organized and offers a summary of the core process for those pressed for time as well as detailed chapters for when you need it. Highly recommended.
Posted on January 4, 2005 09:31 AM | #
8. Keith said:
Krista – I’ve read it! And I’ve been referencing it a bit lately as well. Actually Kelly used to be an employee here at PBDH, and we’re featured in the book. It’s a great book, and has lots of good Web PM tips.
Posted on January 4, 2005 10:48 AM | #
9. James Robertson said:
We do a lot of information gathering (or “needs analysis” as we tend to call it), mostly in the context of intranet projects.
The formal techniques we use most:
* Staff/stakeholder interviews
* Workplace observation
* Contextual inquiry
We also do a lot of facilitated mini-workshops, and a pile of less formal stuff. Basically anything (and everything) that will give us a clearer picture of the business, users, issues, roadblocks, goals, etc, etc.
A couple of brief articles on stakeholder interviews:
http://www.steptwo.com.au/papers/cmb_interviews/index.html
http://www.steptwo.com.au/papers/cmb_interviewselect/index.html
(We are also currently working our way through documenting all these techniques. We haven’t decided how to release it all yet, but it’s looking great, and it may end up in a book format sometime this year.)
Cheers, James
Posted on January 4, 2005 08:50 PM | #
10. Keith said:
James – that stuff is helpful. It’s similar to the way we worked at the hospital (my previous job) but things have changed, now that I’m an external consultant we rarely have access to users like that. Unless someone is willing to pay for it, we have to revert back to some serious work arounds and guerilla user research to gather that kind of information.
As well I’m not sure if an Intranet project would come our way.
On another note – I can’t wait for the book (or whatever) as I find your articles very helpful.
Posted on January 5, 2005 08:48 AM | #
11. Martin White said:
As far as identifying information requirements in the design phase take a look at a recent report by Steve Wood published by FreePint at http://www.freepint.com/shop/report/infoaudit/
Martin White
Managing Director
Intranet Focus Ltd.
http://www.intranetfocus.com
Posted on January 11, 2005 03:25 PM | #
12. Sharaf Atakhanov said:
You should checkout this book called Web ReDesign, Workflow that Works by Kelly Goto. Kelly does a great job summarizing and breaking down the process of designing a web site, intranet or any other web related project into few simple steps.
Her website and the book site have some useful surveys and forms that you can use:
http://www.web-redesign.com/
http://www.gotomedia.com/
-S
Posted on January 14, 2005 07:41 AM | #
Comments are now closed