• Skip to main content
  • Skip to after header navigation
  • Skip to site footer

Shaping Software

Enduring Ideas in the Realm of Software

  • About
  • Topics
  • Best Software Books
  • Archives
  • JD Meier.com

Personas at patterns & practices

Feb 2, 2009 by JD
PersonasAtPatternsAndPractices
Photo by dataScobar

At patterns & practices, we introduced personas a few years back to help design user experience for our deliverables.  Personas helped with a few things:

  • Understanding demographics.
  • Building empathy by putting a face behind the user role.
  • Building a common set of customer examples we can all talk about in meetings. (…Is this for “Art”, “Bert”,”Mort” or “Elvis”?)

I think of a persona as a specific (yet generalized) instance of a role to “personify” and represent what users that play that role, might be like.  While we originally argued over the details of the personas, a great by-product was that we focused on the distinctions across our various customer sets.  This helped reduce ambiguity during product design.  It also helped us make calls on where to put our resources and effort.

One important lesson we learned was that personas weren’t as reusable across groups as they originally seemed they might be.  In other words, we couldn’t just grab a set of personas from another group, and call them our own.  Instead, it meant time and effort to build a set that had specific meaning for our group in the context of what we build.  While our naming overlapped with other groups, we had our own set of reference examples.

Core Personas
Here’s the core personas we originally used:

  • ART (ARCHITECT / PLATFORMS AND PROGRAMMING EXPERT)
  • BERT (DEV LEAD / CORE COMPONENT DEVELOPER)
  • MORT (DEVELOPER)

Additional Personas

Here’s additional personas we used:

  • ELVIS – THE PRAGMATIC PROGRAMMER
  • ISAAC – BUSINESS APPLICATION DEVELOPER
  • SIMON – SYSTEM IMPLEMENTER

Template

For sharing the persona information, we used a simple template

  • Persona
  • Background
  • Environment
  • Job Description
  • Attributes
  • User Experience goals
  • Information Sources
  • What does it mean to create a patterns & practices deliverable for this persona?

Research Behind the Personas

While that was a practical set of info for quick sharing, the research behind the personas included:

  • Overview
  • Household and Leisure Activities
  • A Day in the Life
  • Work Activities
  • Communication and Collaboration
  • Skills, Knowledge, and Abilities
  • Goals, Fears and Aspirations
  • Primary Roles
  • Secondary Roles
  • Fears
  • Career Aspirations
  • Computer Skills, Knowledge and Abilities
  • Technology Attitudes and User Experience Values
  • Tools
  • Issues
  • International Considerations
  • Opportunities
  • Market Influence
  • Demographic Attributes
  • References

Since our earlier days, I think we’ve shifted from persona-based design to more customer-connected engineering.  We have a lot more direct customer involvement throughout the engineering.

My Related Posts

  • Lessons Learned in patterns & practices
  • patterns & practices Solution Engineering
  • patterns & practices Agile Workspace Tour
Category: Design, patterns & practices, User Experience

About JD

Previous Post:The Enterprise of the FutureThe Enterprise of the Future
Next Post:Architectural Styles in Software EngineeringArchitectural Styles in Software Engineering

Sidebar

Recent Posts

  • What is ChatGPT?
  • Agile Performance Engineering
  • What is Cybersecurity?
  • Software Security Threats: A Comprehensive Guide
  • What is Software Security?

Popular Posts

Best Software Books of All Time
Best Practices for Project Management
Best Practices for Software Development
Customer-Connected Engineering
How To Frame Problems Better
How To Pitch Business Ideas Better
How To Structure Vision Scope Presentations
Intro to Lean Software Development
Lean Principles for Software Development
The Enterprise of the Future