Posts Tagged ‘ux’
Agile in Plain English (Part 3)
Posted on: May 30, 2010
- In: agile
- 4 Comments
Working in Agile
So now that you have a definition of agile and some of the underlying principles, how do you actually do the work?
First, it is important to understand that you are not trying to squeeze UX into an agile process, but rather attempting to make the UX process more agile. This will mean being flexible, innovative, and nimble with established UX techniques.
The role of UX
UX practitioners are most successful in the customer role on an agile team. Remember, that customers mean something different in agile, a customer is not someone who is external to the product team who purchases or uses the product. A customer is a role filled by one or more members of the product team, whose duties include acting as the voice of the end-use for the development team, and helping to prioritize and plan.
The customer defines the software, and determines what stakeholders find valuable. The recommended ratio is 2 customers per 3 developers, this means that there are 2 designers for every developer. Designers can be of any combination: UX, Usability, IA, Visual, IxD – whatever is needed to accomplish the project. The customers most important job is release planning which includes:
- Evangelizing the product vision
- Identifyng features and stories
- Grouping features into small, frequent releases
- Managing risk
- Creating an achievable plan
In order to be able to achieve the above, I would recommend starting with:
- Small, clear, and achievable goals
- Letting go of control, and allowing your team help with some of the activities
- Get “good enough” information, and continue to learn throughout the entire project, rather than trying to figure out everything up font
- Be honest with yourself and work towards continual improvement
The Process
The process that has worked best for me was first described by Desiree Sy
The structure basically asks you to:
- Gain initial insights through a short up-front discovery stage
- Get just far enough ahead of development that you are not a bottleneck
- Continually talk to users every iteration to get feedback and more in-depth insights
- Start rough and refine as you go along. utilizing lightweight techniques like sketching
- Establish a clear vision that you are working towards and iterate on the vision as you learn more information
It is important to understand that none of these activities are happening in a bubble, you as the designer are not going off to complete the work and then presenting a finalized design. Rather, you are sketching, concepting, and getting feedback from your entire team along the way. The feedback can be informal or a design critique.
Also, working in this rhythm or cadence will feel uncomfortable at first, and you might have the urge to resist, but stick with it and allow this rhythm to become the “new normal”.
Here are some common objections/questions that I often hear from designers and quick answers:
1) How many projects should a UX designer be on if the company adheres to an agile process?
Answer: ONE. Agile is specifically designed around the team dynamics, and its difficult or impossible to create the proper rapport if you are not sitting and working with the team.
2) Agile methods do not provide enough time for UX practitioners to conduct necessary research and discovery.
Answer: Agile methods do not provide enough time upfront to conduct research, the methodology assumes that you are doing the research and discovery on a continual basis, in every iteration. This not only helps keep the information fresh in your mind, but also allows you to dig deep into questions that arise once you start really trying to solve the problem (later in the project), rather than identifying the problem (as in the beginning of the project)
3) If I break up my design into pieces that can be fit into an iteration, it is difficult for me to picture the holistic system
Answer: Sketch your initial understanding of the holistic system using a storyboard, then begin to dive deep into the parts of the system that are prioritized for the upcoming sprint. Your understanding of the system will change over time, so utilize a low-fidelity medium to capture your current understanding and then update as it – and your understanding – changes.
4) Some designs are too complex to fit within one iteration
Answer: Break large designs into small, cycle-size pieces called design chunks that incrementally add elements to the overall design over several iterations. Whenever you design, you have to start somewhere, start in one iteration and incrementally add complexity / layers in subsequent iterations.
5) There is not enough time to conduct formative usability testing and then create a usability report.
Answer: Employ light-weight usability techniques, and progressively engage in defining test protocols and recruitment.
6) Working software over comprehensive documentation means no more wireframes or mockups
Answer: Use the tools that will help you and your team produce good work. There is no set “way” to do thing, figure out how best to communicate with your team, and which tools help you produce great work in an efficient way, then just do it!
Agile in Plain English (part 2)
Posted on: April 19, 2010
Agile principles and practices
In the first part of this agile series, I explained that there is no such thing as the agile method, but rather a set of principles or values. Specific methods do exist, and they support the agile philosophy. Two of the most popular methods include Scrum and XP. Having only worked in Scrum, I will describe how the practices in Scrum directly support and uphold the principles.
Co-Location: The entire project team sits together in one physical location, rather than being separated into departments.
Supporting Principle: Individuals and interactions over processes and tools
The agile philosophy centers on cohesive, trusting team. That kind of trust can only be build overtime through constant exposure to fellow team members, the demystifying of jobs and daily activities, and just hanging out together. There is also a great deal more cross-pollination of ideas, which leads to a blurring of roles and true teamwork.
Story Creation: Defining the requirements together
Supporting Principle: Working software over comprehensive documentation
The entire team will write stories, which are short requirements statements, versus tomes of requirements documents. They force the entire team to articulate the audience, purpose, and value of each feature.
Customer Demos: Present functioning software at the end of each sprint
Supporting Principle:Customer collaboration over contract negotiation
In Scrum, a “customer” is not a customer is not someone who is external to the product team who purchases or uses the product. A customer is a role filled by one or more members of the product team, whose duties include acting as the voice of the end-use for the development team, and helping to prioritize and plan. UX folks fit perfectly into the customer role!
Stand-Up Meetings: Daily meetings where each team member lets everyone know 1) what they did yesterday; 2) what they are going to do today; 3) anything standing in their way
Supporting Principle: Responding to change over following a plan
This allows the team to gauge progress as well as address any obstacles preventing the team from moving forward.
Retrospectives: A team meeting at the end of every iteration where each team member lets everyone know 1) what went well; 2) what didn’t go well; 3) areas for improvement
Supporting Principle: Responding to change over following a plan & Continuous improvement
Although not stated as an explicit principle, continuous improvement is one of the core values of agile. A team does not need to follow a process dogmatically, but rather learn from each experience, improvise, and improve.
The above represent just a hand-full of the practices that go into a Scrum process. For a much more complete explanation, I would sincerely suggest getting Mike Cohn’s Succeeding with Agile.
Also, check out my full presentation on Slideshare:
Pair Design
Posted on: January 11, 2010
- In: ux
- 2 Comments
Having recently worked at a few companies that are fully agile, meaning both design and development follow agile, versus just development. I have really come to understand the benefits of agile, and you might say, am definitely drinking the agile cool-aid.
One of the things that I like best about agile is the notion of pair programming. I have often watched a pair of developers work together on a bit of code, and was silently jealous because I wished I could have a partner for design! In all of the places that I have worked – even if there is a design department – only one designer gets assigned to a project (unless it is extremely large). So the designers rarely get to work in a team, and are often isolated within their individual projects.
I think perhaps that its time for the design industry to take a cue from agile development and consider pair design.
Let’s take a step back and look at why pair programming works? From Wikipedia, here is a list of benefits for pair programming:
- Design quality: Shorter programs, better designs, fewer bugs.Program code must be readable to both partners, not just the driver, in order to be checked in. Pairs typically consider more design alternatives than programmers working solo, and arrive at simpler, more-maintainable designs, as well as catch design defects very early.
- Reduced cost of development: With bugs being a particularly expensive part of software development, especially if they’re caught late in the development process, the large reduction in defect rate due to pair programming can significantly reduce software development costs.
- Learning and training: Knowledge passes easily between pair programmers: they share knowledge of the specifics of the system, and they pick up programming techniques from each other as they work.New hires quickly pick up the practices of the team through pairing.
- Overcoming difficult problems: Pairs often find that seemingly “impossible” problems become easy or even quick, or at least possible, to solve when they work together.
- Improved morale: Programmers report greater joy in their work and greater confidence that their work is correct.
- Decreased management risk: Since knowledge of the system is shared among programmers, there is less risk to management if one programmer leaves the team.
- Increased discipline and better time management: Programmers are less likely to skip writing unit tests, spend time web-surfing or on personal email,or other violations of discipline, when they are working with a pair partner. The pair partner “keeps them honest”.
- Resilient flow. Pairing leads to a different kind of flow than programming alone, but it does lead to flow. Pairing flow happens more quickly: one programmer asks the other, “What were we working on?” Pairing flow is also more resilient to interruptions: one programmer deals with the interruption while the other keeps working.
- Fewer interruptions: People are more reluctant to interrupt a pair than they are to interrupt someone working alone.
- Decreased risk of RSI: The risk of repetitive stress injury is significantly reduced, since each programmer is using a keyboard and mouse approximately half the time they were before.
The list above can easily be viewed from a designers perspective:
- Design quality: Pairs typically consider more design alternatives than designers working solo, and arrive at simpler, more-maintainable designs, as well as catch design defects or usability problems very early.
- Reduced cost of redesign: With design flaws or usability problems being particularly expensive, especially if they’re caught late in the product development process, the large reduction in flaws can significantly reduce costs. Furthermore, having a pair of designers explain the reasoning behind a design is much more powerful and convincing, and may lead stakeholders to request less redesign.
- Learning and training: Knowledge passes easily between pair designers: they share knowledge of the specifics of the system and domain, and they pick up design techniques from each other as they work.New hires quickly pick up the practices of the team through pairing.
- Overcoming difficult problems: Pairs often find that seemingly “impossible” problems become easy or even quick, or at least possible, to solve when they work together.
- Improved morale: Designers report greater joy in their work and greater confidence that their work is correct.
- Decreased management risk: Since knowledge of the system is shared among designers, there is less risk to management if one designers leaves the team.
- Increased discipline and better time management: Designers are less likely to spend time web-surfing, tweeting,or on personal email,or other violations of discipline, when they are working with a pair partner. The pair partner “keeps them honest”.
- Resilient flow. Pairing leads to a different kind of flow than designing alone, but it does lead to flow. Pairing flow happens more quickly: one programmer asks the other, “What were we working on?” Pairing flow is also more resilient to interruptions: one designer deals with the interruption while the other keeps working.
- Fewer interruptions: People are more reluctant to interrupt a pair than they are to interrupt someone working alone.
- Decreased risk of RSI: The risk of repetitive stress injury is significantly reduced, since each designer is using a keyboard and mouse approximately half the time they were before.
Pair design, think about it!
What is User Experience Design?
Posted on: August 21, 2009
- In: thoughts | ux
- 2 Comments
I had a need yesterday for a quick definition of user experience and its subsequent value to business. I polled the twittersphere and scoured the web but didn’t find any resource that provided a “quick guide” to UX. Since I had an urgent need, I decided to write my own guide. The guide is a combination of my own ideas and resources (see reference list) I found on the web.
What is a user experience?
A “user experience” encompasses all aspects of the interactions an individual has with a company, its services, and its products. An exemplary user experience meets current customer needs and anticipates future needs, exceeds customer expectations, sends a clear and strategic message, and delights the customer with innovative solutions.
For example, when Henry Ford built his first car, he was quoted as saying “If I’d asked my customers what they wanted, they’d have said a faster horse.” A company’s job is not to give users what they want, but to solve problems. The problems that companies are trying to solve are usually social, and so understanding people and how they interact with each other and their environment forms the key understanding and driving force of the product design and direction.
At the core, user experience advocates for the end-user and makes sure to bring the customer’s perspective into the decision making process. In order to achieve this user-centered approach, user experience designers engage in several activities:
- Observe customers in their natural environment to understand how they are currently interacting with existing systems, as well as get insight into how users view the world (their mental models).
- Build empathy and understanding of the customers within the entire product team
- Work with stakeholders to create unified product vision and a user experience strategy. Both the vision and the strategy aim to balance the user needs with business goals.
- Gather further customer data as needed to make educated design decisions
- Utilize sophisticated design methodologies for ideation and innovation of alternative solution to existing options, and constantly ask, “How will this help the customer kick ass?”
- Involve customers in the design process
- Create a structure and organizational system for information environments
- Ensure that the new solutions are useful, usable, desirable, findable, accessible, credible, valuable, memorable, and pleasing
- Continually listen to customer feedback and adapt to changing customer needs
- Keep in mind all the touch points of a user experience and ensure seamless integration between all components
What is the business value in user experience?
In order to be competitive in the current global market, companies are embracing consumers and realizing the power of design. A poorly designed product/service often frustrates customers, which ultimately affects the bottom line. A good customer experience correlates to loyalty. Loyalty corresponds to a customer’s willingness to buy another product from the firm, and a reluctance to switch business away from the firm. As any business knows, it is much more cost effective to keep existing customers than acquire new ones. Furthermore, the strong research aspect in user experience helps business understand why customers are behaving a certain way, and design can help influence behavior. Perhaps customers are dropping off during the checkout flow, not coming back to the site, or not renewing their license. User experience helps to find out why and provides solutions to the problem. For example, changing a single button on a site increased a site’s annual revenues by $300 million: http://www.uie.com/articles/three_hund_million_button
Ultimately, user experience design places a strategic emphasis on the customer, providing value for both the business and the customer. Efficiency is no longer sufficient to be competitive in the current economic climate, a company needs to differentiate through user experience by allowing the customer’s to kick ass, while gaining revenue!
Some cool graphics:
Elements of User Experience Design by Jesse James Garrett: http://www.jjg.net/elements/pdf/elements.pdf
Facets of user experience: http://semanticstudios.com/publications/semantics/000029.php
References
Nielson Norman Group definition of UX
UIE: The Difference between Usability and User Experience
Adaptive Path: Communicate the ROI for Design and Subject to Change: Creating Great Products & Services for an Uncertain World
Kathy Sierra: Subvert from Within: A User Focused Employee Guide
Forrester Research:
Culture and Process Drive Better Customer Experiences
Experience-Based Differentiation
The Business Impact of Customer Experience
Trust and Client Relationships
Posted on: July 9, 2009
I had an “ah-ha” moment recently. The moment was spurred by Josh’s talk at Refresh Boston in combination with my endless job search at the moment, and general self-reflection. I realized two things, which might be seem simple but have actually taken me 3 years to truly understand at an intuitive level, versus just a conceptual one.
1) Although any job will always have times when you might manage difficult conversations, many difficult conversations with clients can be avoided all together if there is a healthy amount of trust.
2) The UX field, either knowingly or not, sends a message that we are the experts. We know best because we talk to the user. This might have come about from the UX field struggling to get accepted as a profession, but has now proliferated so widely that it imbues a lot of work (and discussion lists) and gives newcomers to the field a false sense of righteousness. Theoretically, this might be true (and I would certainly like to believe it), but practically it just does not fly. Our job is not to dictate, but rather to listen, guide, communicate, and facilitate. We do not have all the answers, we are not always right, and we should not take this position when working with stakeholders. One gains much more trust in the service role than in the dictatorship role. I have personally made several huge mistakes by adopting the wrong attitude, which I thought was appropriate for my role as UX designer. I am now thoroughly humbled.
In order to re-educate myself a bit further, I reached out to some of my colleagues – Jeff Parks, Joshua Porter, Steve Baty, and Mark Sloan – and asked them for advice on gaining trust with a client. Here was some of the advice I was given. Most of the information below are quotes from emails.
- Listen. Listen for new insights, listen to understand the clients problem, listen much more than you talk. Ask questions to clarify and repeat back to the client what you have heard. You gain trust by assuring the client that you really care about their problem and are truly listening to them; rather than “pushing a square peg into a round hole”, that is trying to force your framework or mental model onto the client (Jeff Parks)
- Repeat and reiterate what you are working on. This allows clients to feel more confident that you are paying attention and listening (Josh Porter).
- Become a subject matter expert, build a good reputation locally and also within the UX community. Steve Baty suggests writing articles or giving presentations, answering questions in public forums and the like. Clients will cut you some slack when (inevitably) difficulties arise if you have a solid reputation. Also, you need to constantly deliver, so that when things do go wrong, clients know its the exception not the rule.
- Show insight early. Most clients show some misunderstanding, making assumptions about users and their behavior. The idea is to gently push back on that notion by providing insight into user behavior. This shows that you are a subject matter expert and that you can be trusted to make good decisions.
- Be honest. Learn to say “I don’t know” (Jeff Parks), and also be upfront about what you are delivering and when (Steve Baty).
- Plant seeds, and give them time to come to fruition. Know that it takes time for people to learn and make good decisions. What took you a week to decide cannot be related in 10 minutes in a meeting. Plant seeds of ideas and let the client mull it over (Mark Sloan).
- Use terms like “we” and “us”. Anything new will always get some pushback, sit back, take notes and don’t react right away. This will help curb some defensiveness that might come out (unintentionally). The pressure to come to a decision right away is usually the biggest trigger for anger and distrust. Say something like “we don’t seem convinced one way or the other, let’s capture this as an issue, think about it another
day or so and then resolve it”. Using “we” and “us” reinforces the idea that you are working together
and will help both you and them keep the right mind frame. (Mark Sloan).
Do you have more insights than what I listed above? Feel free to comment, I would love to know more tips and tricks!
ETA: I found some relevant articles which bring additional insights to this topic
Understanding Critical to Being Understood by Jeff Parks, Johnny Holland
8 Strategies for Successful Relations with Clients by Jeff Gardner, Smashing Magazine
On Being A Generalist
Posted on: April 10, 2009
- In: design | ux
- 4 Comments
I have been on the lookout for job opportunities since January. Due to the economic constraints at the moment, many job postings want a UX designer with visual design skills who can develop. Although I can do UX design and development, I am not very well versed in graphic/visual design. I was starting to worry that I am missing an important skill.
At SXSW, I spoke with John Kolko and asked him if visual design was a necessity for UX design. He said that since my designs touch the UI, I should understand the fundamentals. He specifically recommended taking class in composition, typography, color theory, and figure drawing.
All of this has been mulling in my head, and then Jared Spool posted this on the IxDA list: http://www.ixda.org/discuss.php?post=40833 Jared mentioned that ROLES don’t matter, SKILLS do, he also said this:
Our research showed there are core skills [that successful teams possess]: interaction design, information architecture, user research, visual design, information design, fast iteration management, copywriting, and editing.
After thinking everything over, including my own concerns, here is how I feel about being a generalist:
First, I completely agree with Jared, the ROLE and role name do not matter, the SKILLS do. People can call me an IA, UX, IxDA, UI, Web designer, whatever, I still bring the same skills to the table.
Out of the skills that Jared listed, here are the ones that I think specifically pertain to UX:
- user research: because we need to understand the domain and the users of the domain
- information architecture/information design: because we need to be able to thoughtfully and purposefully structure the content based on user and business goals
- interaction design: because interaction makes up the large chunk of the experience
- fast iteration management: because our first ideas are never the best ones, fail quickly and often
The skills that I think are “nice to have” but should NOT be required include:
– visual design
– copy writing and editing
– development (not mentioned in Jared’s list)
The “nice to have” skills that I have listed are in this category because they are professions onto themselves, and I think its unreasonable to believe that a UX designer will be able to master 4 different professions. I believe that if one expects this, then they are going to get a designer who is mediocre at everything. There really is only so much time in the day/life that one can dedicate to new skills, or breadth. Drawing on Jared’s analogy of doctor’s, we would not ask a cardio-thorasic surgeon to deliver a baby, why would we ask a UX designer to craft copy? Yes both a surgeon and an obstetrician are doctors and know the anatomy of a body, much like a UX designer and copywriter know the language, but the mastery of the skill is quite different. If doctor’s have specializations, why can’t UX designers?
This is not to say that people should narrowly specialize, I also agree with Jared on this point, if one is too narrow (only doing usability testing for example), then it could certainly hinder your job prospects because you should be able to apply what you learned from the usability testing to create an improved design, the company does not need to hire another person to do that.
However, visual design, development, and UX design often challenge each other, and it is necessary to have the tension for great designs to emerge. If one person is attempting to do all those jobs at once, they will start compromising on the UX as they begin to think about the code or the grid structure. The compromises start to happen conceptually and the designer becomes constrained.
Now Jared mentioned that the UX designer should have the fundamentals of each of those skills, I am not clear on what Jared means by fundamentals, but I think his definition goes further than my conceptualization – which is knowing enough about the domain to be able to communicate with your colleague. I feel that a UX designer needs to understand the basics of programming, visual design, and copy writing to enable meaningful conversations, debates, compromises and decisions. Understanding how your design is going to be developed has a significant impact on interaction, and one needs to understand those consequences. Similarly, if a visual design hinders usability, the UX designer needs to be able to communicate with the visual designer to come to some kind of agreement that does not break the visual flow. Yet, the UX designer should not necessarily have to create the visual design if the designer falls ill, for example.
Given all that I have said, I know many people have entered the UX field from different domains. I personally came from a computer science/programming background, so don’t mind doing front-end development as well as UX design if things get tight. Others might have come from a visual design background, and so can roll up their sleeves and also do that job. This does not mean that the visual designer needs to be able to code at my level, nor I need to be able to design at theirs. We have our respective skills, and will be able to find work that matches our skill set. This is our version of a cardio-thorasic surgeon vs an obstetrician.
My argument is that a good team should have a well-rounded UX designer (possessing all the required skills, with the nice-to-haves as bonuses), along side separate individuals doing visual design, programming, and copy writing/editing. The UX designer must coordinate with all of these people, but not necessarily be a master at all these skills. I agree with Jared that a good UX team should have ALL of these skills present on the team, I just don’t agree that a single individual should or can posses them.
For myself, I have decided to get better acquainted with the language of visual design, I have asked some friends for resource recommendations, and have put together this amazon wish list.
Also, these lessons were highly recommended: http://psd.tutsplus.com/articles/web/50-totally-free-lessons-in-graphic-design-theory/
I know that I will never become an amazing visual designer, but it does not make me any less of a UX designer (who can code none-the-less!).
UX and Agile
Posted on: February 26, 2009
- In: design | ux
- 2 Comments
There has recently been a lot of discussion in the UX field about Agile and how we can integrate our work into the process.
Here are some interesting discussions:
Agile & UX on IxDA List
Leah Buley’s post on Burndowns and Flareups in Agile
In my experience working in an Agile environment at THE_GROOP, I feel like Agile can work, but it ultimately depends on your constraints – clients, time, and resources.
What Works:
- Having a Sprint 0 for UX strategy/research before design and development. This is the time for ideation, sketching, and research. This strategy phase is vital to providing the ground work for the rest of the project.
- Writing out the tasks that need to be completed per sprint, and including iteration as one of the tasks. This allows the designer to get both a broad view and detailed view of the project. It is incredibly helpful to lay out all the tasks that need to be done in a concrete way. By going through this activity (however painful and tedious), it forces you to see what you *don’t know* upfront and then plan accordingly. This is also a good time to talk to other stakeholders and figure out how much documentation is necessary. If the developers don’t want an annotated wireframe, then don’t build it into the schedule.
- If you do the Sprint scheduling with other stakeholders like visual designers and developers, it is really easy to coordinate activities, find out where we can all work in parallel, and also surface the dependencies.
- Burning down at the end of each day feels great (for UX as well!) You also quickly learn how long it actually takes you to do things, so that you can estimate better on the next sprint.
What Doesn’t Work:
- Clients often want to see progress each day/week. Once they see initial design ideas, they have a difficult time letting go (no matter how rough the sketch). This makes it VERY difficult to iterate, or “throw away” designs.
- Aside from clients, time constraints often also restrict design iteration. Unlike code, which could potentially be thrown away and written in any number of ways to do the same thing (with most clients non-the- wiser), design is much more “sticky” because it is so visual. Once you start on a path, you are pretty much forced to continue going down that road. It is almost impossible to completely throw out a design that “just didn’t work” and start from scratch. This is especially true since developers and designers are dependent on the UX work to move forward, so once the ball is rolling, its hard to stop.
- There is practically no time for user research/testing after Sprint 0. You basically have to fit it in guerrilla style (after work or during lunch utilizing fellow co-workers), which doesn’t give you great results or confidence
In general, the visibility of UX work makes it very difficult to generate new ideas, conduct proper testing, and iterate on designs. However, it does force the designer to plan ahead, and get to know themselves a bit better. I do believe agile can work for UX, but perhaps a modified version that takes some of the problems into account.
I am still going to be thinking and developing my ideas about this topic as time goes on, but these are my initial impressions. Will be interesting to see how things change over time!
- In: ux
- Leave a Comment
I recently attended a UX book club in Los Angeles. As part of the worldwide UX book club movement, we read Bill Buxton’s “Sketching User Experiences”. About 20 people showed up for the discussion, which made it really interactive and great. There was certainly discussion about the book itself, with the main insight (for me) coming from the understanding that sketching is like having a conversation, the conversation is the most important part, not the final product. Sketching is a way to think through a problem by utilizing different mental processes, so the final sketch does not matter, rather the insights that you gained from the *act* of sketching does. This makes a lot of sense to my academic side, because discussions were always a big way to surface the questions and inconsistencies I didn’t know existed. I have certainly participated in a lot of class discussions where the act of talking about something truly helped me “get it”, whereas reading the same thing in textbook would never have given me that “ah ha!” moment.
Aside from the sketching takeaway, something that really struck me in our book club conversation revolved around the purpose of personas. I am not sure how we got around to talking about personas (I think I brought it up!), but one seriously insightful individual said the following (I want to call if out for emphasis):
Personas are a way to enable a shared reality with your team
Take a minute to absorb that… Personas are a communication tool for a shared reality. Their purpose is to enable everyone to empathize with your persona and understand them on some level, with the hope that everyone has a similar enough understanding that we are all working towards the same goal.
My biggest beef with personas coming to the meeting was that there was very little buy-in, but how can there be buy-in when I created the personas in a vacuum and then presented them to the team? The team has no stake in the persona, it is just another piece of paper to them. They didn’t invest the time to observe, digest, analyze and write-up the data. They can’t see through the personas eyes as I do, because they have not breathed and lived it like I have. In my experience, the team often takes on look at it and then forgets about it. Which brings me to the question – can a persona adequately communicate a shared reality if the rest of the team was not invovled in its creation?
I am coming to realize that this is not possible, and that the entire team needs to be involved in persona creation (which includes data collection). Then the persona needs to be created as a team (nice whiteboard exercise there!), so that everyone already shares the reality before the formal document is created, and the document is just there as a nice reminder – a solidified form of our shared reality if you will.
Bringing this entire conversation full circle, it seems to me that the *act* of persona creation is the important aspect here, because creating the persona is how one achieves the shared reality with the team, the actual artifact is less significant.
Allaland 