Archive for the 'drivethru' Category

Shared understanding

September 21, 2017

Shared documents aren’t shared understanding.

Jeff Patton: User Story Mapping, p. xxxiii

Advertisements

User stories

August 28, 2017

“The real goal of user stories is shared understanding.”

Jeff Patton – User story mapping, p. xxxiv

Jobs to be done

August 7, 2017

The Jobs-to-Be-Done framework is a representations of user needs born out of qualitative user research, such as field studies, interviews, and discount usability testing. It involves identifying for which goals customers “hire” your product (and, ideally, also finding out if there are competitor products that these users are ready to “fire”). Armed with this understanding, a product team can think about the nature of the users’ core problems and needs from a fresh perspective, and devise product features that solve that main need as best as possible.

For example, if a traditional task analysis unearthed that delivery drivers frequently needed to print out directions that showed how to navigate between each stop on their daily route, it’s likely that the design team would focus on making it as easy as possible for the drivers to format and print the directions; however, a JTBD-focused approach would focus on the delivery driver’s “job” (that is, getting navigation guidance while driving), and would look for solutions to that problem (such as a GPS system providing voice guidance).

Oftentimes, we hear JTBD advocates referring to the famous Theodore Levitt quote, “People don’t want to buy a quarter-inch drill, they want a quarter-inch hole.” Rather than focusing on a list of features for a product, the JTBD framework forces designers to think about outcomes: would users be able to (happily and easily) complete the job they “hired” the product for? Does this solution provide a better outcome than existing ones?

From: Personas vs. Jobs-to-Be-Done by Page Laubheimer

 

 

 

Replacing The User Story With The Job Story

August 1, 2017

Summed up, the problem with user stories is that it’s too many assumptions and doesn’t acknowledge causality. When a task is put in the format of a user story ( As a [type of user], I want [some action], so that [outcome] ) there’s no room to ask ‘why’ — you’re essentially locked into a particular sequence with no context.

[Suggested job sytory]

We frame every design problem in a Job, focusing on the triggering event or situation, the motivation and goal, and the intended outcome:
When _____ , I want to _____ , so I can _____ .
For example: When an important new customer signs up, I want to be notified, so I can start a conversation with them.

Alan Klement: Replacing the User Story with the Job Story

All models are wrong

August 1, 2017

“All models are wrong, but some are useful”

George E.P. Box

Cognitive load is lessened with rounded shapes

June 20, 2017

According to research, it’s harder for the brain to process sharp edges — the cognitive load is lessened with rounded shapes.

Molly Mc Hugh

Research:

https://www.fastcodesign.com/3020075/why-our-brains-love-curvy-architecture

https://www.webdesignerdepot.com/2012/11/stop-being-so-square/

http://www.cns.nyu.edu/~david/courses/perception/lecturenotes/depth/depth-size.html

Interface as text

June 6, 2017

“How would I explain to a friend, in a conversation or in an email, this thing/topic/product/story I am trying to communicate?”

Fabricio Teixeira: Storyframes before wireframes: starting designs in the text editor

 

Nash equilibrium

June 1, 2017

In a Nash equilibrium, every person in a group makes the best decision for himself, based on what he thinks the others will do. And this inevitably ends up being a bad decision for the collective.

A. Madhavan: Why we need a dating app that understands Nash’s equilibrium

Service design blueprint

April 9, 2017
A blueprint is an operational tool that visualizes the components of a
service in enough detail to analyze, implement, and maintain it.
Blueprints show the orchestration of people, touchpoints, processes,
and technology both frontstage (what customers see) and backstage
(what is behind the scenes). They can be used to describe the existing
state of a service experience as well as to support defining and implementing new or improved services. While service blueprints resemble approaches to process documentation, they keep the focus on the customer experience while showing how operations deliver that experience.
Nick Remis / Adaptive Path

Design the beginning

October 31, 2016

The “beginning” is how you introduce something new to a person, and how you will get them to understand its value such that they incorporate it into their lives. When you set about designing the beginning, you are forced to consider the following hard questions:

  1. Where and how will people first hear about your product or feature?
  2. What should people understand about your product at a glance, and is that compelling enough to convince them to go through the trouble of trying it out?
  3. What should people’s first-time experience through your product be, and how do you plan to demonstrate to them its value within the first minute?
  4. How will you build out the social graph, content inventory, marketplace, etc. if the success of your product is dependent on those things?
  5. What would compel somebody to come back and use your product a second or third time?

Julie Zhuo: Design the Beginning