by Jeff Patton

Pragmatic personas can be fast, based on user research, but can also draw on your own experiences (according to Don Norman)

Identify User Types or Roles

• Different kinds of people are user types (student, professional)
• User Role describes the relationship a person has with your product (thing-doer, eg late night pizza buyer, daytime lunch seeker)

Profile User Types

Personify User Types to Create an Example User

Consider Product Design Impact

Mike Cohn – (slides)

Software requirements are a communication problem; balance is critical.  If business side dominates, functionality and dates mandated with little regard for constraints.  If tech dominates, we make them speak technical jargon and we lose the business need, drivers.

We cannot perfectly predict a software schedule.

So…we make decisions based on the information we have, but do it often

We spread decision-making across the project, rather than making one set of decisions…

Stories

Stories are (Three C’s, Ron Jeffries)

• Card (Note card) – Most visible part
• Conversation – Promise from dev team to product owner: “We will come talk to you before we start”
• Confirmation – Acceptance criteria

Short story about a system feature told from the perspective of a user.

As a …<user> I want to…<goal> so that…<reason>

Sometimes, you need more detail about a story.  You can:

• Create new, smaller, more specific stories.
• Define ‘conditions of satisfaction,’ which are really acceptance tests.  “What does the product owner need to see so that we can know this story is done?”  This basically becomes the ’script’ for the Sprint review.

User Roles

Broaden scope from looking at one user

• Allow users to vary by:
• What they use the software for
• Hwy they use software

This is different than a persona, where personas are about a specific user (based on research), designed to induce empathy in the design team.  User roles are more broad, describe types of users.

Can do user role brainstorming to identify different roles:

Thinking about your product, everyone writes a role on an index card.

• Brainstorming, no judgement on what the roles are
• Put related roles near each other
• Combine, consolidate, remove

Advantages of using roles

Avoid saying “The user”.

Can also have system and programmer users.  “As a payment verification system, I want all transactions to be well-formed XML…”

Stories, Themes, Epics

User Story – Description of desired functionality told from user perspective
Theme – Collection of related user stories
Epic – Large User Story

Themes, Epics don’t really imply size…Themes aren’t necessarily bigger or small than Epics.  They’re just labels.

This is the followon session to the previous Guerilla User Research session.  The theme here is taking the insights learned from User Research and turning them into actionable design.  The goal of this series of talks is to demo an application on Thursday this week.

Communicate Design

• Personas
• Workflow Stories / Scenarios
• Task Analysis Grids

Personas

• Quote
• Day-in-the-life story.  Contextual/specific to what the person is doing right now.
• Goals
• Pain Points/Frustration
• Opportunities
• Activities

Design tool

Storytelling

Way to build empathy on users

Based on user research

Todd talked about the DNA chart…

Workflow Stories

Scenarios are stories that happen in the day of a life of a key user.  A narriative form that tell a story of people using the system.  Tasks are the granular items, connected to how important it is to different users.  This can be used to prioritize possible features.

Empathy is one of the key points of why we do user research.  This is a bit of contention with the Agile methodology and ‘user stories.’  User stories may refer to ‘average user,’ which often means ‘me.’

Good to use multiple points in order to generate personas:

• Project Stakeholders
• Customer Representatives (Customer Service Reps)
• Actual Customers
• Someone you know

Task Analysis Grids

Work back and forth between personas and Task Analysis Grids.  The idea is to get a holistic view of what the system is supposed to do overall.  Then go back to figure out the order/priority in which features are built/released.

• Scenario Based
• Incorporate personas
• Prioritized

Persona Creation and Critique

We broke into several groups.  Each group created a persona based on the user research generated in the previous session.

Russ Unger, Todd Zaki Warfel

Traditional barriers to UX research: Time and Money; customer/stakeholder perceived value, and the attidude that “We don’t have time and money to do this.”

Argue, “We don’t have time and money to NOT do this…”  Spend a few hours doing some research, in order to allow you to make data driven design decisions

Each methods have strengths and weaknesses.  It’s good to combine multiple methods

The Burrito Lunch

• Send out an email, if you fit a profile, come do this, and we’ll give you lunch
• Chocolate snacks are a helpful way to get people to fill out surveys

Crowd Sourcing

• Using social media, other tools to get people to give feedback.  E.G.  Twitter, Facebook
• Coupled with web analytic data

Man on the Street

• Simply just going out and asking people, note trends.

User Research: “You never ask the question you really want answered.  If you ask the question you want answered, you’ll miss all kinds of rich information.”

User Research…one of the benefits of the agile UX methods is that you can bring prototypes to user research sessions: gives you access to users, do validation of current design, and research for future sessions.

Designing the Box

• Get people together, some Sharpies, paper, ask people to design the box the product, tool, service would come in.

If this was a COTS product, what are the key features that need to be front and center.  As a UX designer, gives you insight into the thought processes involved in prioritizing features, etc.

Guidelines for asking better research questions

• Provide context: “Did you have coffee yesterday?  How much coffee did you have yesterday?  Was that a normal day?  How about the day before that?”  It’s our job as researchers to ask questions and identify trends, amounts, etc, rather than asking them directly?
• Helpful to start with a most recent or most memorable experience.
• Start broad and open ended
• Funnel and narrow questions

People want to tell you about their lives.  If you can facilitate in a way that allows them to tell their own stories, people are willing to talk.  Another way to help people talk: “I’ll share a story about me, then you share a story about you.”

I’m heading to the Agile2009 conference next week, and looking forward to it.  It’s sort of fun watching the twitter chatter about the conference.  Some ads/pimping products and services, but also some of the conference presenters are talking about how they’re getting ready, and even posting their slides!

Someone retweeted this video from Ward Cunningham (yes, the one that invented the wiki) about the metaphor of ‘technical debt.’  Basically, when you are coding short term solutions that you know don’t completely address the core problem your code is designed to address, you are incurring ‘debt,’ similar to the way you incur debt when you borrow money.  Until you repay that debt, more and more of your effort will be consumed servicing the debt.  You’ll spend all your time patching holes, and won’t have any time to address new features or take on new projects.

This metaphor is directly applicable to one of my work projects.  It turns out that when we originally designed the system, we ‘missed’ a requirement.  After the product went live and business users started seeing it, they realized that there was something else it needed to do in order to align with their business rules and customer contracts.  Since then, we’ve had to build certain workarounds in order to address this discrepency.  Cunningham would argue we’ve incurred technical debt, which we need to repay by refactoring and revising our code in order to reflect our current understanding of the business processes. 

That refactoring/revising is a key part of Agile development.  We have a few challenges with that.  First, I don’t think we have enough unit test code coverage to be confident our refactoring doesn’t break anything.  Second, it’s difficult for us to find time to go back and fix things because all the new things people are asking us to do are piling up, and of course those are higher priority.  I think agile people would say we need a Kanban process.  Third, the powers-that-be don’t see the value in going back in reorganizing something that ‘works,’ so it’s hard to argue for the need to service our technical debt.

I’m hoping to learn more about how to address these challenges at the conference.

Textmate has the ability to create new files based on a template you create.  It had a few templates for Python, but nothing exactly like I want.

When I start a new python script or module, I want to:

• Follow the Pythonista style
• Parse some command line arguments – usually an input file
• Enable logging (either file based, or to the console)

I created a new TextMate template to do those things.

1. Select Bundles > Bundle Editor > Show Bundle Editor
2. Select and Open the Python Bundle
3. Find the Python Bundle Templtes
4. Copy one into a new Template.  Give it a sensible name
5. Replace the template.py text with the following…

#!/usr/bin/env python
# encoding: utf-8
"""
untitled.py

Created by Jerry Steele on 2009-08-12.
Copyright (c) 2009 ACT. All rights reserved.
"""
import os
import sys
import logging
import optparse

LOG = None

def process_command_line(argv):
 """
 Return a 2-tuple: (settings object, args list).
 `argv` is a list of arguments, or `None` for ``sys.argv[1:]``.
 """
 global LOG
 if argv is None:
 argv = sys.argv[1:]

 # initialize the parser object:
 parser = optparse.OptionParser(
 formatter=optparse.TitledHelpFormatter(width=78),
 add_help_option=None)

 # define options here:
 parser.add_option("-f", "--file", dest="filename",
 help="read data from FILENAME")
 parser.add_option("-v", "--verbose", dest="verbose", default=False,
 action='store_true', help="write debug log to FILENAME")
 parser.add_option("-L", "--log", dest="logfile", help="write debug log to FILENAME")
 parser.add_option(      # customized description; put --help last
 '-h', '--help', action='help',
 help='Show this help message and exit.')

 options, args = parser.parse_args(argv)

 # check number of arguments, verify values, etc.:

 # set up logging
 if options.verbose:
 LOG = setlogging(options.logfile)

 if not options.filename:
 pass
 #LOG.error("Input filename not specified")
 #parser.error("You must supply an input file")
 # further process settings & args if necessary

 return options, args

def main(argv=None):
 settings, args = process_command_line(argv)

 # application code here, like:
 # run(settings, args)
 return 0        # success

def setlogging(logfile=None):
 consolelevel = logging.DEBUG
 logger = logging.getLogger(__name__)
 logger.setLevel(consolelevel)
 # create formatter and add it to the handlers
 formatter = logging.Formatter("%(asctime)s - %(name)s - %(levelname)s - %(message)s")
 # create console handler with a higher log level
 ch = logging.StreamHandler()
 ch.setLevel(consolelevel)
 ch.setFormatter(formatter)
 # add the handlers to logger
 logger.addHandler(ch)

 # create file handler which logs error messages
 if logfile:
 filelevel = logging.ERROR
 fh = logging.FileHandler(logfile)
 fh.setLevel(filelevel)
 fh.setFormatter(formatter)
 logger.addHandler(fh)

 #test logging
 logger.debug("debug message")
 logger.info("info message")
 logger.warn("warn message")
 logger.error("error message")
 logger.critical("critical message")

 return logger

if __name__ == '__main__':
 status = main()
 sys.exit(status)

Even if you don’t use Textmate, you can still use this to quickstart python modules.  Just remove/replace the $TM_ variables