Category: General

Ethnographic Fieldguide

From http://picography.co/

I’ve gushed before over Just Enough Research before, Erika Hall’s outstanding primer on UX research and thinking about research in a broader commercial sense, but this morning I came across a hidden gem.

In re-reading Chapter 5, I came across a link that I had missed before, to the Helsinki Design Lab – specifically their Ethnographic Fieldguide, a concise, delightfully Finnish document that outlines a manner of thinking and approaching research from an ethnographic perspective. What does that mean?

Ethnography aims to get under the skin of human behavior, to better understand the world and the specifics of the cultures we live in. The focus of the research can be anything from current cultural tendencies, to changing values, attitudes and norms, or concrete human behavior and its motivations within different situations and contexts.

You can find the Ethnographic Fieldguide, and learn more about the HDL, here.

The most radical, audacious thing to think is that there might be some point to working hard and thinking hard and reading hard and writing hard and trying to be of service.

Mark Vonnegut, Armageddon in Retrospect

Ticket Non-Ownership: Reflections

After doing some ruminating here as well as the discussion over on UserCentered, I decided to iterate a little on the idea of Ticket Ownership with my squad over at Automattic.

For the month of April, we eschewed  all ownership of our incoming support requests. What does this mean, exactly? Traditionally, our approach is this: the first Happiness Engineer to respond to a customer then replied to that customer each time they supplied more answers or information, until the issue was resolved. This past month, rather than seeing tickets as being owned by an individual, we owned our entire queue of tickets as a team – focusing not on ownership, but rather replying to the tickets strictly in terms of wait time – whichever customer waited the longest got the next reply, regardless of who had interacted with them in the past. Another way to look at this is this: we were evenly distributing the wait time across tickets, which is reminiscent of line balancing, a method of improving capacity use in production settings.

Wonderland_Walker_2
As April came to a close, I spent some time talking with the rest of my squad, seeing how they felt about the whole idea, if they wanted to continue, and what they saw as the upsides and downsides of this sort of non-ownership. Here are the two big advantages that non-ownership offered:

  1. It created an informal peer review: in reading through a support request’s history, you are able to see in very clear terms how other members of the squad approach different problems, as well as getting a first-hand look at their writing style, tone, and use of outside links (both to WordPress.com support documents and other tools).
  2. It allowed the Happiness Engineer team to much more quickly identify bugs when compared to full ticket ownership: this is because we were exposed to a much larger number of conversations per day, thus making patterns in customer reports much easier to spot than a traditional ticket ownership system, where it is much easier to write off a customer’s problem as misuse or misunderstanding rather than as a broader systemic bug. You can imagine if a Happiness Engineer replies to one customer 6 times regarding a potential bug, it will be cognitively less obvious as a problematic pattern than if the same Happiness Engineer replies to 6 customers a single time each.

And the negatives:

  1. Each particular support request felt less personally involved, and less personally invested, and at least from the Happiness side, thus felt less hospitable.
  2. Working on a request that someone else had already replied to felt more time consuming, as the Happiness Engineer had to re-do the legwork of researching the customer’s site, background information, etc.
  3. Highly time sensitive replies are answered at the same pace as other tickets, since the wait time load is evenly distributed.

Moving forward, we’re hoping to find a way to embrace the advantages while removing or reducing the negatives.

P.S. Does this sound fun to you? Does working on a small team providing hospitality to an enormous userbase seem like a worthwhile pursuit? Would you be able to restrain from strangling a Squad Lead who pulled this kind of experimentation on you? Good news – we’re hiring.

 

Bad Process Kills

To do good work consistently, you have to have process – a way that you approach The Work that allows you to create a feedback loop, allows for continual improvement, and ideally helps you to identify the important things that are sometimes buried in the day-to-day. Process helps you to be satisfied with The Work – good process helps you to be happy, and great process is rare and fleeting but worth the chase. Bad process fails in one of these ways: perhaps you don’t get the information that you need. Perhaps you don’t know who to ask for help. Maybe it’s as simple as not knowing the best way to organize your day.

Have you heard of Jack Phillips?

On the evening of 14 April, in the wireless room on the boat deck, Phillips was sending messages to Cape Race, Newfoundland, working to clear a backlog of passengers’ personal messages that had accumulated when the wireless had broken down the day before. Bride was asleep in the adjoining cabin, intending to relieve Phillips at midnight, two hours early. Shortly after 9:30 pm, Phillips received an ice warning from the steamship Mesaba reporting a large number of icebergs and an ice field directly in the path of Titanic. Phillips acknowledged the Mesaba‘s warning and continued to transmit messages to Cape Race. The Mesaba‘s wireless operator waited for Phillips to report that he had given the report to the bridge, but Phillips continued working Cape Race. The message was one of the most important warnings Titanic received, but it was never delivered to the bridge.

The Titanic’s epic capsizing can be attributed at least in part to bad process: Phillips had the information that he needed, and he knew what he needed to do – transmit that information to the bridge. What his process lacked was a mechanism that helped the important stuff float to the top. Instead, this urgent message that would have changed history sat beneath a stack of messages from the passengers to their friends back home.

Bad process kills. Get rid of it before it gets rid of you!