How UXD Can Provide Leadership Skills for Complex Software Projects: A 4-Day Plan

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]