Posted by jc-Qualitystreet on 2011/03/08
Activity #2 of the Agile UX practitioner…
(See the Activity#1: Vision)
The Agile UX practitioner creates Personas collaboratively…
A persona is a user-archetype, a fictional representation of target users you can use to help guide decisions about product, features, navigation, visual design…
Persona "Sophie" (for a french banking project) Contexts-Goals-Implications in an agile way. Personas workshop
Personas are an essential element of the product Vision envisioned at a strategy level. They represent the first sections of our Vision formula (from Geoffrey Moore): FOR (target for the product) …WHO (users’ needs), a key element of the famous elevator pitch.
The persona approach provides a team with a common and shared understanding of the users of a service or product (but also what they want, their behavior, their needs and expectations) in a very engaging format, easily linked to Agile User Stories.
In short, personas are a fantastic way to integrate real User Experience all along the product development project.
And this is the role of the Agile UX practitioner to be the Personas promoter and to initiate their creation in collaboration with the Product Owner and the Team.
Create the Personas with Agile Teams
Everything starts at the beginning of the project, before sprint 1 (a sprint 0 or short exploration is an appropriate period for doing it). But, the persona approach requires mobilizing the entire team around it and should be envisioned collaboratively.
- Organize one or two workshops with the Product Owner and various stakeholders in order to be aligned to the objectives and the approach, to identify data sources, to determine categories of people to interview (for example the core roles)
- Inform the entire team of the process
- Then collect data from various sources including user interviews.
2 Construct collaboratively
- Analyze data (facts) in collaborative workshops using affinity diagram and identify variables then patterns
- Create the Personas skeletons
- Give birth to the personas (including storytelling, writting and visual design) using the format you prefer (formal or not)
- Validate the results with various stakeholders
A Persona Template (more formal)
3 Communicate & Use
- Include the Personas on the Information Radiator within the team environment
- Link the Personas to User Stories
- Use them as a prioritization tool (in the Product Backlog) and a designing tool (related to specific user stories)
- If necessary, make a communication plan for marketing and sales activities: make a buzz!
Personas Ericsson Life in 2020: Make the Buzz!
Posted by jc-Qualitystreet on 2010/11/21
Agile development and user experience can work brillantly together… well, but how?
Even if the effort related to Agile User Experience (Agile UX) continues throughout the project (with « just in time » designing and user testing) the User Experience foundations must be initiated at the very beginning of the project, during the first sprints.
Starting to define the Product vision is a best practice. Key element of the vision, the PERSONAS (a fictional representation of target users you can use to help guide decisions about product, features, navigation, visual design…) have also the precious advantage to be directly linked to USER STORIES (brief description of functionality as viewed by the user and an essential agile artifact).
A persona template
First sprints are also the best moment to create a coherent vision of the User Interface structure, and to establish first Usability guidelines (then UI patterns), two elements that will enable UX specialists to maintain a consistent user interface across features and regular deliveries.
Once the product vision and posture established, the target users defined and the product backlog (list of all functionality desired) initiated, user experience of the application will continue just in time, sprint after sprint, following the iterative and incremental lifecycle.
Trust and collaboration are the keys, and UX practitioners MUST BE collocated with development team: visual artifacts, storyboards, mockups and wireframes, will serve the project and enable business and development teams to build the best user experience.
Wireframe with balsamiq: quick, easy and collaborative
But agile development lifecycle proposes new challenges and requires managing User Experience differently…
Support user representatives or business teams (Product Owner) in their analysis, specification and prioritization effort…
UX specialist is the user advocate but also Product Owner partner as well as a team member.
Do just enough user Research, user modeling and UI design up front
The Agile Persona : quick and easy
Adapt your collaboration with teams during a sprint:
- Progress one step ahead of the implementation by preparing and designing « just in time » contents of next iterations (sprint+1, sprint+2)
- Collaborate actively with developers on the functions that must be delivered at the end of the current sprint
- Evaluate with end users results of the previous sprint (sprint-1)
Consider feedback differently: direct, less formal, more frequent and more reactive both in the way to receive and to give it. Overuse face to face collaboration, guerilla usability testing and just enough reporting & documentation
Use rapid prototyping (effective wireframes) to foster collaboration and elicit rapid feedback. Make it valuable and adjusted to the context
Paper prototyping ... from collaborative workshop
Be a facilitator and engage people (both business, development and end-users) on collaborative workshops to design and evaluate the system
Anything else ?
Posted by jc-Qualitystreet on 2010/10/18
Larry Constantine is the co-author with Lucy Lockwood of « Software for Use » (1999), well-known in the HCI (Human Computer Interaction) field for his « Essential use cases technique » and his « Usage-centered design methodology ».
He wrote an article (part 1 and part 2) a month ago on Agile and Experience Design Marriage, with an introduction a bit provocative:
« when experience design is married with agile development, the results can be a crisis of faith on either or both sides »
In part 1, Larry insists on deep philosophical differences and variance in practices… As a UX practitioner and Agile Coach, involved in various agile projects, I unfortunately have to confirm some of his observations:
- Agile methods still don’t incorporate usability and UX practices
- Marriage is often « one way », experience designers accommodate to the dictates of agile methods and schedules, even if UX tend to become now the key differentiator in the IT marketplace.
- UX is not the key driver for development
- UX is still a lack in most agile projects
That said, I don’t agree with, what Larry Constantine calls « core incompatibilities » in the couple. What a negative approach!
Of course, « agile methods employ rapid, iterative refinement, with short, incremental development cycles« . And, yes, « they tend to favor a functionality-first, inside-out process, beginning with early and easy successes that deliver working code« . So what? Is it so incompatible with user experience and usability techniques? I don’t think so!
Rapid prototyping, Guerilla usability testing, Personas and just enough user research, innovation games, Vision or Design workshops are examples of fabulous UX & Usability techniques. They can be effectively applied within agile development cycles.
I rather see the iterative and incremental development as an opportunity to gather, at frequent intervals, feedback… real feedback… rich feedback. Receiving feedback from the team, the customer or of course the users is, according to me the most important element on IT projects.
Time to market, value and simplicity are now crucial for most organizations evolving in a highly competitive environment. It is both a reality that UX specialists need to understand and a strength that lead them to focus only on valuable activities. And I am really convinced that we need to adapt our approach, our tools and deliverables for more effective collaboration with other actors involved in IT projects (not only agile…).
In part 2, Larry Constantine described in detailed the key ingredients to make a better marriage between Experience Design and Agile Development…
- Respect of each other’s work and skills (I personaly think we’re all professionals)
- Equality in the development process (I personaly think User Interface Design should be considered as an essential prioritization criterion of the product backlog !
- Knowledge about each other’s skills and areas of expertise… to get respect and equality (I personaly think learning is a key whatever the context !)
- Independence though but coordinated activity
… A more optimistic view that I appreciate. I also like his conclusion:
« Now, may your union be a long and prosperous one! »
Posted by jc-Qualitystreet on 2009/12/02
« Life is easy with personas » …
this is what I’ve been told by a client the last time I used the Personas method on an IT project.
A persona is a user-archetype, a fictional representation of target users you can use to help guide decisions about product, features, navigation, visual design…
http://www.slideshare.net/toddwarfel/data-driven-personas Todd Warfel (UPA 2007)
More than a simple artifact or a one-page description, the Personas method is a user centered design technique, initiated by Alan Cooper in 1999. It provides a team with a common and shared VISION of the users of a service or product, in a very engaging format.
Why personas are relevant in Agile contexts?
In agile projects, Personas should be seen as a fantastic tool in the hands of a Product Owner team (composed by the Product Owner, a User Experience specialist, a Business Analyst…) to align the cross-functional team (dev, test …) to a shared and realistic vision of the users of the product to develop.
Personas provide you with the opportunity to integrate real User Experience all along your product development project.
Indeed, they enable the team to stay continuously focused on user primary goals and tasks by emphasizing what they want, their behavior, their needs and expectations but also their potential impediments
Another major benefit is that a specific persona can be easily linked to user stories. The « user voice format » is a good opportunity to place the personas under the spotlight. It makes your user stories more credible, more engaging. It also facilitates CONVERSATION and CONFIRMATION activities associated to each user story.
Personas are a powerful communication tool within and outside of the team. They can be used at the organization level for training, commerce or marketing activities.
How to proceed?
Option 1: Using existing Personas
Personas are ready when you start the project ; just use them !. User research was done previously, and personas are already a key element of the product vision. No need to construct them, but the Product Owner has to introduce the personas to the team when he communicates the Vision. One of the benefits of the personas is that it makes this description easier, both visual and based on storytelling. Based on that knowledge, Elevator Pitch or Product Vision exercises will be more effective with the team.
Then during the sprints, personas are associated to user stories, and help guide decisions on the Product Backlog priorization and UI design. Crucial, don’t you think ?
A classic example with Zylom (not current version):
Two personas (Maria and Sophia, whose main goals are to play online, download games to play offline and get help if they need it) and their impact on UI Design in terms of color, shape, size, positioning of elements, layout and navigation menu structure.
Of course, Personas can also be used for testing activities: scenario based testing, usability testing, cognitive walkthrough …
I usually ask the team to include Personas on the Information radiator. It is an important communication act both from an internal and external perspective.
Option 2: Constructing new Personas
Personas don’t exist when the project starts.
Sprint / Iteration 0 is the perfect moment to initiate our « 3 steps » process, of course in a collaborative way. This exploration sprint usually lasts from one to four weeks, depending on context.
Unfortunately a short timebox (one week for example) is a real difficulty especially for organizing workshops and planning user interviews. You’ll need to anticipate or to refine ….
Given availability issues, various impediments … « 8 user interviews a week » is usually a maximum (actually it’s mine), but it gives you the opportunity to facilitate preparation workshops and to do quick stakeholders interviews in parallel.
You may understand why I like a duration of 3 or 4 weeks for a sprint 0 🙂
Here is my process to build personas:
Step 1: Preparation consists in:
- Organizing one or two workshops with a Product Owner team and various stakeholders in order to be aligned to the objectives and the methodology, to identify data sources, to determine categories of people to interview (for example the core roles)
- Informing the entire team of the process
- Collecting data from various sources including user interviews. According to me, 3 interviews by roles or categories identified is a minimum.
Step 2 Construction consists in:
- Analyzing data: from facts to behavioral variables, then from variables to patterns
- Establishing Personas skeleton
- Giving birth to the personas (storytelling and Poster) : I initiate the work (based on a template and data analysis) but I like doing this task in one or two workshops (this time with the entire team, development included). It’s fun and fosters the appropriation process.
Personas: A template
- Validating personas with various stakeholders (a qualitative validation); I only did one time quantitative validation with a large questionnaire sent to hundreds of users.
Step 3: Communication & use consists in:
- Putting the Personas on the Information Radiator
- Linking the Personas to User Stories
- Using the personas for priorization, storyboarding and wireframing activities
- Making a communication plan dedicated to the Personas
- Mobilize the entire team around the approach
- Limit the number of Personas
- Define a primary Persona
- Start the personas construction with the Product Owner team, but inform and finish it with the entire team
- Anticipate three or four workshops in the agenda
- Bring your personas to life using big cards or posters containing a name, a title / role, a script (the storytelling allowing good back in the character’s life), a picture, goals, triggers, influencers, delighters, features expected …
- Be careful on the choice of the photo: avoid celebrities, models or people you may know. remain credible.
- Don’t hesitate to communicate on your Personas: make a buzz !
Posted by jc-Qualitystreet on 2009/01/18
12 best practices compiled by Jeff Patton that have proven their efficiency with multiple teams.
Here is the list of the emerging practices with a quick review.
1 Drive: UX practitioners are part of the customer or product owner team
MUST User Experience activities support analysis and prioritization tasks carried out by of the Product Owner (scrum) / Client (XP). This can go up to write User Stories and even play the Product Owner role. This position does not harm our cooperation with the development team. In one of my recent projects, we had a Product Owner Team (speaking one voice) working with the UX consultant to facilitate understanding and putting User Stories into context.It was very efficient.
2 Research, model, and design up front – but only just enough
MUST Sprint 0 offers us a good opportunity to do our job, but timeframe is diiferent … UX must go straight to the point: personas, quick modeling…Sprint are short (2, 3 or 4 weeks) and people expect expertise from us.
3 Chunk your design work
MUST No choice but not an easy thing. During the first iteration, it is a real difficulty.
4 Use parallel track development to work ahead, and follow behind
MUST It is a real challenge but it is also the most exciting part of the job in an Agile context. During a specific iteration (n), UX practionners have to:
- design the content of next iterations (n+1, n+2)
- collaborate with developers on the current iteration
- evaluate results of the previous iteration (n-1)
5 Buy design time with complex engineering stories
CAN Very contextual.
6 Cultivate a user validation group for use for continuous user validation
CAN It helps and it is great if the pool of users is the target (but the pool must be large enough). It could be also a way to initiate change…
7 Schedule continuous user research in a separate track from development
CAN A question of time and resources but impossible if there is only one UX guy in the organization…
8 Leverage user time for multiple activites
SHOULD OK, but do not forget that visiting users for nterviews, questionnaires, card sorting, screen reviews requires time for preparation, analysis and restitution…
9 Use RITE to iterate UI before development
MUST Feedback and adaptation are the keys. Teams do not want to wait; they don’t care about a formal and standard usability testing reports.
10 Prototype in low fidelity
MUST Paper, PPT, Visio, whiteboard … everything is OK if you give value to the team and the project.
11 Treat prototype as specification
MUST Always ! High level Storyboard + User Stories + Wireframes : a magic potion
12 Become a design facilitator
MUST It is my conviction : facilitation is the future of our profession !