How to communicate

Identify your audience

A persona describes one specific category of users.

Davenport is a senior chief petty officer in the U.S. Navy, one of 18 culinary specialists chosen to compete for the title of Armed Forces Chef of the Year.

Examples:

• A prospective student
• A logged-in content editor
• A customer
• A client app that gets content from your feed or API
• A forum poster
• A viewer

Now ask the audience to describe Derrick Davenport as a user.

Describe the need

("User stories" in Agile-speak)

Examples:

• "I want to find the application deadlines."
• "I want to schedule posts for publication later."
• "I want to add the item to my cart."
• "I want to find articles about salamanders."
• "I want to reply to a post."
• "I want to watch a video."

Now ask the audience to describe Derrick's need to slice bananas for pie, as a user story.

Clarify that they are not describing the banana slicer, but rather his need to have sliced bananas.

Include context

("So that..." in Agile-speak)

Examples:

• "...so that I can apply to the school."
• "...so that I can maintain a steady stream of published content."
• "...so that I can review what I’m about to buy."
• "...so that I can display an arbitrary number of results."
• "...so that I can participate in discussions."
• "...so that I can be entertained."

Ask the audience to add a "so that..." describing why Derrick needs all those banana slices.

Define "Done"

("Acceptance criteria" in Agile-speak)

Examples:

• "Given the homepage of the site, when I navigate the main menu, then I find a link to admissions information."
• "Given a saved blog post, when I edit it I can set a publishing date in the future, and when that date arrives the post becomes visible on the blog."
• "Given a product page, when I click "add to cart" then I can see my cart contents and the new item is included."

Ask the audience to propose acceptance criteria for the banana slicing task.

Mitsakes

Mistakes

Mistakes in describing a project

Commonaudience identificationmistakes

Consequences ofaudience identificationmistakes

“As a member of the board,I want to see something flashyso that I can show it off”

Commontask descriptionmistakes

• "...a website that works"
• "...[specific JavaScript library, Drupal module, etc.]"
• "...a form for login that redirects me to my page that tells me when I last logged in and asks me to place a new order."

Just right: "...to turn one banana into many half-inch thick, circular slices." (Make the audience propose a few before giving away.)

Consequences ofneed descriptionmistakes

These mistakes indicate a lack of a vision about what the users will actually do.

Commoncontext clarificationmistakes

• "..." [no “so that” at all]
• "...so that I can [restates the "I want..." almost verbatim]"
• "...so that I can [states another, separate need that should be its own "I want..."]"

These mistakes indicate a lack of big-picture cohesion.

Consequences ofcontext clarificationmistakes

These mistakes indicate a lack of clarity about how this task fits into the overall project.

"...so that I can decorate the top of the pie." (Again, make audience propose some first.)

"This is not what I meant by 'dress the turkey'!"

Common"done" definitionmistakes

• "I assumed this would work like our old site.""Obviously this shadow on the comp means a popup on hover.”
• "Given a website, when I do [task], then it works"
• "When I [task] then I can also [completely new task]."
• "When I log in an HTTP request goes to IP address 127.0.0.1 which generates response."

The common thread in all of these is that they fail to define "done". They lack an explanation of the criteria that you (or your users) will apply to determine whether the product works.

Consequences of"done" definitionmistakes

These mistakes indicate a lack of clarity about how product will be tested.

When to communicate

(hint: it's before you think you need to.)

• Before you talk to developers
• When the project starts
• When you have a blocker
• Early and often

This is like...

• ...making sure you have all the ingredients before you start cooking.
• ...making sure that your sous-chefs understand the recipe before they start chopping.
• ...working on the crust while the filling sets.
• ...checking the recipe card whenever you're unsure of something.

Beforeyou talk to developers

• Users+needs drive the project.
• Record likes & dislikes about other solutions.
• Prepare with user data
  • What browsers need to be supported?
  • What parts of your site are the most-used?
  • What is "intuitive" for your users?

Pictured above: what happens when you try to add a pinch of nutmeg after the pie goes in the oven.

When there's ablocker

(part of the project is waiting on another part of the project)

• Other development tasks
• Missing information
• Does NOT include just being unavailable.
• If you're blocking someone
  • Find out their need.
  • Keep them updated.
  • Don't second-guess. Don't take back tasks that have already been started even if it seems like it would be faster. In the short run, it might be. In the long run, it creates bad habits and communication overhead. The cost of correcting a few imperfections is almost always much less than the cost of constant second-guessing.

Scheduling

("Sprints" in Agile-speak)

Schedule = priorities + dependencies.

Prioritizing

• Who are you prioritizing?
  • End users?
  • Admin users?
  • The chairperson of your board of directors?
• What are you prioritizing?
  • Intuitiveness and simplicity?
  • Fanciness and slickness?
  • Robustness and ease of maintenance?

Sorting

"Good enough" vs. "Cool extras"

Prioritizing Tasks

• Ordinal prioritization
• Avoid “do everything first” syndrome.
• Clicking and dragging items in a list enforces this.
• If it's not there, it's not done.

Re-prioritizing

• It's like brushing your teeth.
• Don’t change priorities on work that's been started/scheduled.
• “Project time” != development time.