Upload
greg-laugero
View
2.900
Download
1
Tags:
Embed Size (px)
DESCRIPTION
This presentation was given at the Usability Professionals Association 2008 Conference. It is for UXD professionals who are ready to take their next career step and move into a leadership role for complex projects. We'll discuss practical techniques, along with hard-earned lessons, for bringing order to the often overwhelming chaos of difficult projects.
Citation preview
How UXD Can Provide Leadership Skills for Complex Software Projects
A 4-Day PlanGreg Laugero
Industrial Wisdom, [email protected]
720-249-2400
Who Am I and Why Am I Here?
• Co-Founder of Industrial Wisdom• Leader of the UXD/IA practice• Co-Author
– Managing Knowledge: A Practical Web-Based Approach
– Enterprise Content Services
• Clients– GlaxoSmithKline– Microsoft– British Telecom
The UXD Opportunity
• We can move from practitioners to leaders.
• We have techniques and methods—a language—that can help bring order to these chaotic projects.
• We just need the courage, conviction, and opportunity to do it.
Software in the 1990s
WebsitesEnterprise
Software(ERP, CRM)
Owned by Marketing
Built by Agencies
Extension of Advertising
Owned by IT
Built by SIs
Extension of Operations
Right Brain
Visual-Design Driven
Left Brain
Process DrivenSkills
Requirements
Use Cases
Software Code
Deliverables
Brand Guidelines
Creative Briefs
Photoshop Files
Software in the 21st Century
RIA, Kiosks, Mobile
Enterprise Software
(ERP, CRM)
Personas and scenarios
Flows & wireframes
Usability testing/eval
Good-looking HTML
Deliverables
Complex project mgmt
User experience design
Info Architecture
Usability assessment
Analytics
Skills
Owned by business & IT
New business channels
More than websites
RIA, Kiosks, Mobile
Enterprise Software
(ERP, CRM)
Merging Roles
UsabilityProfession
al
Business
Analyst
IA/ID
UXD
Chaos Reigns
• Business can’t tell IT what it wants– Businesspeople think IT “doesn’t get it”– IT thinks the business is confused– Software companies get blamed
• Director is “in over his head”– Unrealistic executive expectations– Not sure where to start– Under or “wrongly” staffed– Wants to believe that technology will be the hero
• Most of these projects fail to deliver their objectives
How do you know…?
• Requirements gathering sessions mired in error and exception cases.
• Timelines are rarely settled.• Management’s expectations are
continuously reset.
The UXD Opportunity
• We can move from practitioners to leaders.
• We have techniques and methods—a language—that can help bring order to these chaotic projects.
• We just need the courage, conviction, and opportunity to do it.
The 4-Day Plan
Goal Deliverable
Day 1 Get Fundamental Questions Answered
Entity RelationshipsHigh-Level Requirements
Day 2Identify “Happy
Paths” and Exceptions
Use Cases
Day 3 Go to Work Flow Maps
Day 4 Present the Results Presentation
Session Goals
• Learn how to turn UXD and usability skills into a foundation for leadership
• Learn a 4-day, focused approach for gaining control of potentially complex software projects
• Experience practical techniques and deliverables for the 4 days
• Understand the mind shift that is necessary to assume a leadership position in complex software projects
You might be skeptical…
• Can you really do this in 4 days?• How do I get the authority to do this?• Do I really need to follow all steps? • Is this really my job?• Who should be in the room?
Is four days realistic?
• It depends…– on the scope of the project– on the willingness of the participants– on the availability of the participants– on your workload
• Treat 4 days as 4 steps.• Bring energy and get a lot done on day
one: you’ll guarantee participation on subsequent days.
How Do I Get the Authority?
Your Own Knowledge and Experience
(Believe in Yourself)
Convince Yourself
Make the Case(to Yourself first)
Ask
Do I need to follow all steps?
• It depends…– Complexity of your project– Existing methodologies– Timelines
• If you skip a step, do it deliberately and know how you’ll close the gap.
Is this really my job?
• It’s somebody’s job.• It might as well be yours.• UXD provides the language, techniques,
and skills to facilitate.
Who should be in the room?
• Core Group:– You– The person responsible for
the success of the system– The person responsible for
implementing the system– The person responsible for
documenting requirements– 1-2 SMEs
• On the bubble:– Technical architect– The person responsible for
supporting the system
Core Group
On-Call Individuals
Stakeholders
Personas: Your Cast of Characters
• Dealing with unrealistic management expectations
• Doesn’t understand staffing needs
• Probably inherited technology decisions
Director, Deer in the headlights
Motivation: Needs a successful project for credibility and advancement
Success looks like: Initially a deployed system, but will soon learn that results are key
How to handle: You must make him/her look good at every step.
Personas: Your Cast of Characters
• Lots of institutional knowledge (often technical)
• Knows the details and is proud of it
• Will make anything more complicated if he can
Mr. Exception Case
Motivation: Most comfortable in the analysis phase -- infinitely
Success looks like: Validation from others as to his institutional knowledge
How to handle: Channel his energy and validate his input
Personas: Your Cast of Characters
• Thinks he knows UXD because he uses the web
• Will try to show off through criticism
• Perpetuator of myths and outdated ideas
Mr. Web “Know It All”
Motivation: To be visible, perceived as “smart,” and heard
Success looks like: Seen as having deeper web expertise than you, especially if you are a vendor
How to handle: Validate input, but defend your decisions with evidence
Personas: Your Cast of Characters
• Often a key stakeholder• Rarely looks up from laptop• Attention will ebb and flow
The Multi-Tasker
Motivation: Involvement in everything
Success looks like: Providing just enough input to make the project successful (but no more).
How to handle: Don’t fight the trend. Work with it.
Personas: Your Cast of Characters
• Executive without much relevant experience
• Often talked about, rarely seen
• Probably is only interested in visual design
The Absent Presence
Motivation: Not sure, since he/she is rarely in the room
Success looks like: Ditto
How to handle: Help the team make intelligent decisions and hope for the best
Overview of Method
Justification Requirements
Design BuildFunctional
Requirements Test
UX Modeling
DetailedRequirements
DetailedRequirements
Competitors
Personas
Flows, IAWireframes, User Testing
Flows, IAWireframes, User Testing
Prototyping
Pri
mary
Acti
vit
ies
Secon
dar
yA
cti
vit
ies
Front-endDevelopment
Front-endDevelopment
User AcceptanceTesting
User AcceptanceTesting
Flash, Flex, AJAX
Metrics
System Strategy and Vision
System Strategy and Vision
DetailedWireframes
DetailedWireframes
Metrics
Today’s Discussion: The 4-Day Plan
Day One: The Basics
• What types of users do you have?• What does each type of user do?• What are the underlying structures that
govern the relationships between users and tasks?
NOUNS AND VERBS
Day One Scenario
Nouns and Verbs
Director: We have accounts that are on contracts with distributors and others that are not. Our contract accounts have special pricing and purchase their products through a distributor – not directly through us. But we still want them to be able to use the website. That is, we want to be able to sell them products, but they should get their contract pricing and the distributor should get credit for the sale.
Web Know-It-All: The system has to be easy to use. I know that when I go to a web site, if it isn’t easy to use, I just won’t go back. I mean, if I can’t find what I want in three clicks, I’m outta there.
Mr. Multi-Tasker: Direct customers purchase from us, and they don’t have contracted pricing. They get standard pricing.
Mr. Exception Case: Yeah, but what about customers who purchase for more than one account? How do we handle them? What happens when they log into their account in the system?
Director: How many of those do we really have?
Mr. Exception Case: I’m not sure. We’d have to look that up.
The Multi-Tasker: What about recurring orders? Our competitors do this. We need to let our users do this too.
Nouns and Verbs
• Explicit Nouns– Contract Accounts– Direct Accounts– Distributors– Users– Products– Orders
• Implicit Nouns– None
• Explicit Verbs– Place an order– Sign-on
• Implicit Verbs– Set up an account– Modify an account– Research products– Check order status– Check order history
Entity Relationships
0 to many
1 and only 1
1 to many
Accounts
Customers
Products
Nouns Verbs
Nouns connect to
other nouns using verbs
manages
includes
orders
Underlying Structures
What is the relationship:• User• Account• Contract
Username + Password Accountmanages Contractmay have
Underlying Structures
What makes up a contract?
Contract
Billing Location
Pricing Plan
includes
includes
Shipping Locationincludes
Underlying Structures
What is the relationship:• Order• Account• Contracts
Account Contractmay have
ProductOrder contains
Belongs to specifies
Implied Tasks
What can the user do?
Username + Password Accountmanages
ProductOrder
places or views
contains
Belongs to
researches
Entity Relationship Diagram
Implied Complexities
One user needs to manage multiple accounts
When placing an order, the
user may need to
specify an account and a
contract.
Not all products will be available
to all contracts – dynamic
product lists and prices
Minefields: Confirm Decisions
Day One: Lessons Learned
• Create formal deliverables (though abstract). • Don’t be exhaustive. Focus on key issues.• Revise them if they change later.
Do this publicly. • Hold everyone accountable to the decisions
made on Day One.• It can be expensive to go back on these
decisions.
Day One: Other Considerations
• Are “Personas” useful at this stage?• What about “Scenarios”?• How do “Mental Models” fit in?• How to integrate Competitive Analysis?• How to use Market Research?
Day One: Other Considerations
• Mental Models– Helps you make design decisions for Use Cases– Attitudes, concepts, emotions that a persona
musters when trying to make sense of a goal or task
• Competitive Analysis and Market Research– Provides input to personas, scenarios, and use cases.
persona participates in scenario use caseyields
UX Modeling and Market Analysis
Market Education versus Placing OrdersShows relationship between Ordering and Educational content.Last Updated: 6/13/2008
Decision Maker
Website
From whom should I buy?
What should I buy? Market Education
Place OrderCheck Status
PurchaserHow do I purchase from the company?
What is the status of my order?
What information does this person need to make a
positive buying decision?
What information does this person need to successfully
complete an order?
Handwritten list
Market Education versus Placing OrdersShows relationship between Ordering and Educational content.Last Updated: 6/13/2008
Decision Maker
Website
From whom should I buy?
What should I buy? Market Education
Place OrderCheck Status
PurchaserHow do I purchase from the company?
What is the status of my order?
What information does this person need to make a
positive buying decision?
What information does this person need to successfully
complete an order?
Handwritten list
Different personas undertake different tasks (verbs)
Division of Labor
Tasks + Personas
• Tasks mapped to primary and secondary personas
• Roadmap for Use Cases
Day Two: Happy Paths/Exceptions
• How will users accomplish tasks?• Focus on Use Cases.• Happy paths come first.• Exceptions follow.
START SIMPLE, LAYER ON COMPLEXITY
Day Two: Audience Participation
What are the high-level tasks? • User sets up new account• User researches products• User selects and purchases products• User creates recurring order• User places recurring order• User modifies recurring order• User views status of existing orders• ….
Anatomy of a Use Case
• Make a list of known complexities– Multiple accounts– Multiple contracts
• Address them systematically
• Start with “happy path”
• Layer on complexity
Day Two: Lessons Learned
• Same as Day One.• Use a whiteboard to structure people’s input. • Stay focused on the simple paths first: “What
is the most straightforward, least complex user situation?” (This is how you deal with Mr. Exception Case.)
• Layer complexity on the simple paths as exceptions: “What happens to the happy path if…”
• Identify important content as part of each Use Case.
Day Two: Other Considerations
• How do Use Cases jump start Information Architecture?
• Why can’t I just start with wireframes?
Day Three: Uninterrupted Work
• No meetings.• Turn Use Cases into Flow Maps.• Just the right level of complexity:
– know who is going to use your documentation
– and how they will use it
DEVELOP YOUR OWN FLOW MAP STANDARDS
Day Three: The Flow Map
• Major pages and other presentation methods (e.g., “lightbox layers,” email, chat interfaces)
• Numbering scheme for pages• Different user’s progressions through the flow• Major conditional drivers of the flow (e.g.,
authentication, customer types, personalization) and where they are relevant
Example Flow Map Key
Example Flow Map: B2B Ordering
Example Flow Map
Example: Move Telco Services
Day Three: Lessons Learned
• Same as Day One• Know the level of detail required by
your audiences and deliver it.• Take responsibility for covering all Use
Cases.
Day Four: Presentation
• Confirm major decisions.• Bring it all together.• Focus on the Flow Map.
REACH CONSENSUS
Day Four: Presentation
• Revisit Entity Relationships: key underlying structures– Users, accounts, contracts– Accounts, orders, contracts, pricing
• Review all tasks• Review Flow Maps
– All major pages that will be wireframed next– All major content for each page– How users will progress through the pages– All major conditional drivers of the flow
Day Four: Lessons Learned
• Same as Day One• Emphasize the major decisions – this is
a big accomplishment.• The Use Cases and Flow Maps will be
“documents of record” for the project and must be revised if requirements change.
Day Four: Other Considerations
• What’s next?– Content models– Wireframes– Functional specifications
• More market research?• More user research? • How will you measure the success of the
system? – You now have enough information to define Key
Performance Indicators.– Define a metrics strategy.
Conclusion: The Mind Shift
From Practitioner to Leader• UXD provides a way of thinking that bridges the
language divide among stakeholders.• You are part of an implementation team, not just
a UXD or usability expert.• Leadership requires a method, and method
requires flexibility.• Need to see the “big picture,” which may mean
learning new skills.
Conclusion: Mind (Career?) Shift
Usability
Profs.
Business
Analyst
IA/ID
UXD
Contact
Greg LaugeroPresident, Co-FounderIndustrial [email protected]