Internet R&D

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.’

Categorized as Process

Lockheed Project Management

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.

Categorized as Process

Customer Service Organization

Dear Mr. Lombardi,

I will forward your comments to our E-commerce department to see if this information can be added to the error screen. Please let me know if I may be of any further assistance.

Thank you,

Member Service Officer

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?

Categorized as Process

Retail Design

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.

Categorized as Process

Intertwingled Conversations

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.

Categorized as Process

Writer’s Workshop Critique Format

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.

In summary, the steps are:

  • Preparation
  • Welcoming
  • Author reads, then becomes a fly on the wall
  • Summary
  • Positive comments
  • Constructive comments
  • Summary of good points
  • Author’s questions
  • Applause
  • Unrelated story

I’ve tried it a couple times with limited success. I’m interested to know if others have used it or if it could work in an online critique format.

Thanks to Jan Borchers for sharing this format with me.

Categorized as Process

Usable, Useful, Desirable

I’ve been thinking that different kinds of artifacts have different ratios of usability, usefulness, and desirability. It’d be nice to express this at the beginning of a project to set everyone’s expectations and syncronize design approaches. But how to express it?

Perhaps by analogy?

high desire, moderate usability

moderately high desire, despite low usabilty

only moderate desire, but high usability

low desire, low usability

Usefulness seems like a contextual and subjective quality, not a quality of the artifact itself. I could imagine owning two very different coffee makers and each would be more useful depending on the situation. A percolator is the best choice when you’re camping.

Ultimately usability and desirability are relative too. For example, my sister-in-law loves the coffee from her percolator. As usual, it’s important to know who you’re designing for.

Same idea, in PDF format.

Categorized as Process