Category: Process

Mr Patent: ‘There’s an endless series of problems, things that the company needs us to solve, and we go and do that.’

I wonder if any Internet companies have dedicated R&D departments for finding solutions to problems (as opposed to developing new products), or if we all keep fixing the same things repeatedly in different situations?

Another quote from that article: ‘But you know what? Universities are slow! They’re collections of individuals doing their own research. I missed working for a big organization with smart colleagues who were all in it together, working toward a single goal. But it took me a few years to figure that out.’

Fast Company has an interesting article on the management approach at Lockheed Martin that led to winning the U.S. Joint Strike Fighter contract. One important point is the willingness of the Pentagon to prove out the technology during the bidding process: ‘The defense department gave both Boeing and Lockheed $1.1 billion in funding to develop prototypes for the head-to-head fly off, and it set up a fire wall on the amount that each company could spend directly on the JSF.’

Another point is their approach to doing a premortem:

The team’s best hope for staying on schedule is to anticipate problems and fix them before they occur. To do that, managers from Lockheed and its partner companies, Northrop and BAE, undertook an ambitious postmortem: They compiled an exhaustive database of setbacks and lessons learned on virtually all of the world’s modern tactical-aircraft development programs. Then they did a premortem: They plotted their lessons-learned analysis on a graph that runs from 2001 to 2011. The graph enabled them to identify 10 future inflection points — dates when the risk of a setback runs high.

I’ve done postmortem’s to learn the mistakes of a project, and premortems to guess what may go wrong on a new project, but to plot the potential pitfalls over time extends the benefits of this planning process further than the initial meetings.

Dear Mr. Lombardi,

An email from my bank, this is the same problem as when I was designing a bank site…the poor saps handling the customer support are not the same poor saps designing the system, so there’s no direct connection in the feedback loop between designers and the public. Of course the designers need some time to design, but they sure as hell would make the site more friendly if it meant cutting down the amount of support they had to field.

It gets even worse when you factor in the rest of the experience. Tonight I was lulled in by the wonderfully egalitarian ads for The Neighorhood thinking this was the revolutionary phone service that was finally customer-driven (turns out it’s MCI’s local phone service, but that’s irrelevant). By listening to their radio ads, I thought it was mobile service, not landline. What are the chances that my feedback on their advertising will go through MCI’s centralized customer support down to The Neighborhood department and back to their ad agency? Maybe like, never.

It seems like a problem of scale, that after a certain size the communication just doesn’t happen. But it’s improbably a small company could offer phone or banking services and compete with the big companies. Where’s the sweet spot between the two, and is it possible to stay there without getting too big or too small?

Her shop in Brooklyn is small but cozy. In a line around the walls are framed samples of her work with inlaid photos of the happy customers. The storefront blends in with the others on the block. The simple sign over the window reads, ‘Websites – Cheap.’

Patrons come in and chat about what they’d like. She asks a few questions about who the site is for and what will be on the site, then she shows them a few sites to get an idea of the overall scale. Sometimes the patrons relax in one of the big, comfy chairs and browse through the large 3-ring binders that serve as catalogs. The catalogs are sorted by website style and include price and time estimates for each design. The colorful screens are interspersed with questions like,

‘Serious, or fun?’

‘What will your website say about you.’

‘How will people feel after visiting your site?’

Normally she sits behind the counter quietly working on her computer. Occasionally she gets up to chat with the folks hanging out and refills their lemonade.

Sharing a desk with Craig, I noticed it’s not unusual for him to be talking to one team member on his mobile while conducting multiple simultaneous IM sessions.

Looking for a Lighweight Way to Receive Peer Feedback

In the past I attempted to improve the quality of information architecture work on the department level using heuristic analysis. It’s relatively easy to do, but in reality I found analysis sessions difficult to run because 1) the presentation and feedback process is time consuming due to the scope problem: IA covers a large problem area, and 2) heuristics alone are unstructured, possibly causing blank-sheet-of-paper syndrome.

I tried accomplishing similar results using a format borrowed from writing groups, described below. We used it at the design patterns workshop at CHI 2000 and it was very successful.

To address the scope problem, we’d only review an approach instead of an entire architecture. An approach could be summarized by touching on

• the users
• the business scenario
• one path, one use case, or one blueprint

…and be expressed in under 20 minutes (figuring the entire exercise could run about an hour). The idea is that suggestions on an approach should help guide the IA through the rest of the architecture.

Writer’s Workshop Format

This version contains my modifications to include heuristics

In preparation, all critics have familiarized themselves with the IA approach before the workshop. One of the critics, the facilitator, provides an initial welcoming, the author first reads a part of her work to the authors, to remind everybody there’s a person with feelings behind the work. After this introduction, the author fades into the background and attends the following discussion without interfering (called a fly on the wall). One of the critics now summarizes the paper in his own words and the others can add to this summary. Next, the critics refer to the heuristics and offer positive comments on the submission, and subsequently constructive suggestions (what could be improved) are collected. The discussion ends with a summary of the good points of the paper (this sandwich technique avoids a negative lasting impression). After this, the author is welcomed back into the group and allowed to ask questions if some comments were not clear to her, or if she wishes to see another aspect of her paper discussed. She is not allowed, however, to defend her work at this time. As this whole discussion can be a bit harsh at times, the author is finally applauded for her work (and courage to submit it), and, to round out the activity with levity, somebody closes the session with an entertaining unrelated story.