Groundswell author on blogging a book

· Teamwork, The Power of Many

Back when I wrote The Power of Many I blogged about blogging a book in progress and since then I’ve noticed a number of other authors blogging about the same subject. (Contrast this with William Gibson’s decision to stop his blogging when he started his next book.)
Now it looks like Forrester analyst Charlene Li and her collaborator are using a full suite of “living web” tools to write their book, Groundswell (why does that name sound familiar?): Groundswell (Incorporating Charlene Li’s Blog): 7 ways the Web makes writing a book better & faster:
> 1. Collaboration with a wiki. Charlene and I have put as much as we can into a SocialText wiki. It’s contains research interviews, title ideas, the latest table of contents, the elements of the proposal that got us here, everything. I just added a page which tracks all the chapters as they move through various writing, editing, and review stages. We don’t generally use the Wiki to write the chapters — the drafts still move back and forth by email, partly since SocialText can’t quite handle all the formatting flexibility that MS Word can — but copies of the chapters do live there. A bicoastal collaboration needs a wiki. We also share it with other interested parties including my boss, Charlene’s boss, and our editor at HBS Press.
>
> 2. This blog for testing ideas. I can’t count the ways that a blog helps. When we think we have a good idea, it goes up here. For example, the five goals of a company for social computing, which became the core of the book. We put our outline up here for your review. That post became extremely useful, because I reference it in every email I send to people I’m trying to influence or interview. People doing interesting things contact us because of the blog. And I’m not even getting to the uses of the blog for promotion, which will start after the book is written, but well before it’s published.
>
> 3. Del.icio.us for gathering research documents. Every story, vendor, YouTube video, and anything else on the Web gets tossed into the del.icio.us bucket. I rarely used to bookmark things — now I bookmark everything. These sites are even classified with our own proprietary set of tags that indicate what chapter they relate to. (We’ll share this when the book is closer to done — right now it’s proprietary.) I don’t believe we could have written this book without del.icio.us.
>
> 4. Email for everything — but highly personalized. Every single contact in this book — and there will be hundreds and hundreds — will have been made by email. I’m sure you’re not surprised that I email Charlene 10 times a day and do a few IM conversations, but I’m talking about making introductions by email. If I need to introduce myself to somebody, I send a personalized email describing the book in one sentence, linking to the blog post about the book, and telling them what I want and making it clear I have researched them and know what they are about — and I frequently get a response the same day. This email might take 15 minutes to write, but it’s worth it — it’s the opposite of mass emailings, highly personal and personalized. (I recently invited a CEO to speak at our Forum in October and got an affirmative response within two hours — astounding our events team.) Where do I get the email addresses? Forrester has a database that may or may not help. Easier is finding the PR email address on a company’s site. Often somebody I know, knows it. Sometimes I use Zoominfo’s PowerSearch. And sometimes, if I know the email address of somebody else at the company, I guess based on that format. That actually works — recently got the CEO of an Italian company to get back to me that way.

At first I had big spreadsheets full of contacts I was pursuing on Google docs but I’ve found a better way. I just flag all incoming and outcoming mail that relates to contacts. The yellow flag means I’ve pinged somebody and need them to get back to me. Then I just check all those flags when I’m in followup mode. It’s not ACT, but it works for me!
>
> 5. A big monitor in a quiet office. When I am ensconced in my home office with my high-speed Internet, VOIP phone line, home network, and big flat monitor, I am highly productive. The big monitor has made a big difference — I no longer feel cramped and squeezed by my laptop screen, and I frequently have one thing up on the laptop (like a Web site, or edits I need to address, or an interview) while I write on the big monitor. When I’m not at home, my productivity goes down. My home office, while it’s in the basement, also has a window out onto my lawn, a fireplace, a hardwood floor, big whiteboards filled with the stuff I’m working on and my kids’ artwork, and quick access to the kitchen and my family when I need to decompress. Makes all the hours possible.
>
> 6. A phone line that follows me anywhere. Forrester has an Avaya phone system with a cool little feature — an Internet app I can run on my laptop that turns any phone into my office phone. At my home office, I can call Japan using Forrester’s phone system, conference people together, transfer them to other Forrester extensions — everything I can do at my desk. And if I go anywhere else, I can do this with any phone line — my mobile, Forrester’s Foster City office, or my parents’ house. People see my caller ID as if I were calling from Forrester, and my voicemail is one click away. I find this far better than giving everyone my mobile phone number.
>
> 7. Firefox and Netvibes. I use Firefox for everything possible, because the tabbed browsing and the bookmarklets make it very efficient for me. I cannot survive without tabbed browsing since I am typically browsing 4 or 8 things at once to build a chapter. (I know IE has tabbed browsing now but it’s too late, I’m happy with Firefox.) I use Netvibes to track a surprisingly small number of blogs including Micropersuasion, The Church Of The Customer, The Long Tail, Blog Maverick, and Seth Godin. I also have up TechCrunch, GigaOm, TechMeme, and TechDirt, but they post so frequently that I don’t read them unless something catches my eye.
(via allaboutgeorge)

Lessons from failure at Boxes & Arrows

· Information Architecture, Teamwork, User Experience

I am curating a series of articles at the venerable information architecture (and user experience) web magazine Boxes and Arrows, based on the panel I moderated on the same topic at this year’s IA Summit.
The first article in the series is Joe Lamantia’s It Seemed Like the Thing to Do at the Time: The Power of State Mind. Joe looks at the big picture, literally, comparing business failure ot catastrophic societal failure, using the Easter Island culture as a case study (as well as his own experience with a startup).
I’m really glad to see this article published because we had limited time on the panel and I wanted to hear more of Joe’s thoughts about these scenarios.
Fascinating stuff and more to come.

My slides from the IA Summit

· Applications, Design, Events, Information Architecture, Mobile, Teamwork, User Experience

Here are my slides from my presentation, Mobile Information Architecture: Designing Experiences for the Mobile Web:

(I may update them with a 2.0 version based on some new learnings from subsequent conversations, and a different idea of how to pace the imagery.)
And here are my slides from the panel I moderated, Lessons From Failure: Or How IAs Learned to Stop Worrying and Love the Bombs:

Scope and spec via task analysis grid

· Teamwork, User Experience

Todd Warfel shared an interesting deliverable, The Task Analysis Grid, a sort of visual substitute for a requirements document, saying

Personally, I’ve yet to come across a requirements document that is usable and doesn’t take a couple of days to get everyone on the same page. So, we use something different – a task analysis grid….

Each column starts out with a scenario, describes a task and is followed by all the sub-tasks necessary to complete the task. The sub tasks are colour-coded and prioritized from 1 (must haves) to 4 (some day in the future).

This is one of our most successful artifacts during the design process (next to personas and wireframes). A client once said that this artifact “takes our 60 page requirements document and distills it down to one page.”

[E]ssentially, this single document allows anyone looking at it to see the entire scope of a project, figure out what’s in this release (1) as well as what we’re planning for future releases (2, 3, and 4). It’s an extremely effective artifact for getting everyone on the same page.

IAI website redesign documents

· Teamwork

I wrote a little blurb for the IAI Newsletter this month introducing the information architecture deliverables we’re using to guide the relaunch of the Institute website:

WEBSITE REDESIGN
We’ve all heard the cop out about the cobbler’s children having the worst shoes. Most of us have probably made that excuse about our own neglected personal websites as we spend all our time working for clients or doing paying work. But everyone agrees that the website for the IA Institute needs to be exemplary. It should exhibit solid IA fundamentals, a great user experience, and seamless usability.
We all know that the current site falls short of these targets in several respects. There has been a site redesign project underway as long as I’ve been a member of the Institute. When I joined the board of directors this fall I expressed some interest in the progress of the website relaunch and was rewarded with the role of IT/Web director. I began reviewing the documents associated with the redesign project and was impressed by the depth and thoroughness of the process and deliverables. I suppose that shouldn’t have surprised me, given the core capabilities of so many of our members. (The site relaunch, just like the original site, relies entirely on the volunteer efforts of our members.)
So, in the interests of transparency and as a way of sharing with our stakeholders some insight into the redesign process, we’re including a link to our IA concept documents for the site redesign in this newsletter (and we plan to continue posting our documentation as the project continues to give our membership some visibility into the progress we’re making.)
View the concept map on the IAI website.
Note that these are final deliverables and we are not circulating them to seek amendments or suggestions. The project is well on its way based on these IA documents. We are close to selecting a final design approach and volunteers are busily implementing some of the new technical features and grooming the old site content.
In fact, we are seeking a volunteer to help review and revise the content in the Education section of the site, so if you are interested, please contact Melissa Weaver at volunteer AT iainstitute DOT org to volunteer.
Christian Crumlish,
IAI Board of Directors
Information Technology/Web

The deliverable includes some conceptual maps, some use cases, a navigation map and a set of wireframes. Hat’s off to Wolf Noeding, who created the documents based on research, surveys, and input from the members and board of the Institute.

Teamwork Comments are off for this post.

Stakeholder mapping

· Teamwork

On the IA Institute mailing list Patrick Walsh recently asked, “Is Stakeholder Analysis/Mapping a commonly used tool by IAs? It helps to identify all relevant stakeholders at the start of a project and can help ensure that they do not get overlooked.” He also pointed to a 2004 article in Boxes and Arrows by Jonathan Boutelle called Understanding Organizational Stakeholders for Design Success.
As long as I’ve been doing IA and related work I’ve understood stakeholder *interviews*, at the very least, to be a cornerstone of the discovery process. I had just assumed this was par for the course. Isn’t this how everyone does it?
Often the challenge is getting beyond the obvious stakeholders and getting access to the external stakeholders. There are a number of techniques for doing this, some qualitative (surveys, focus groups, interviews) and some quantitative (traffic analysis), but often I find that we need to rely on internal people, such as customer-support representatives, as proxies for external stakeholders because they at least have direct contact with them and are aware of some of their most pressing concerns.

Teamwork Comments are off for this post.