Personas discussion in context of use case, competition for the use case

Boris Mann's picture

Thanks to @rickvug for kicking off the personas discussion.

I feel pretty strongly that the community owner / site owner and community member / site user are the two most important personas from a priority perspective.

eaton's description of the overall target / use case is:

[tsunami] is currently meant for small groups of individuals who are collaborating on a project and want to communicate with each other, tell the world about their project, and attract other people who are interested in helping. Imagine a small open source project, a local community group seeking to renovate a park, or a club that needs to keep in touch between meetings and attract new members.

I think an addition to this should be some guiding principles:

  • the primary usage of this site will be by users
  • that is, when choosing between a site building use case and a user-centric use case, Tsunami will lean towards the user-centric use case

I think it's useful to think about what the "competition" for this use case is. I see Basecamp (mainly message posts), Google Groups, and Ning being the main targets. Even a simple mailing list should be considered competition.

Even more importantly, all of those tools are competition for something I hope to stamp out in my lifetime: chains of emails with 20+ people on them. Organizations that "lose" information in these email threads, or that fail to build on knowledge of tasks they've done before.

So that's my argument on prioritizing community site owner and site user as personas. Thoughts?

Comments

I like it.

eaton's picture

I also think that you make an important distinction -- mailing lists, ning, google groups, and basecamp aren't feature competitors to Tsunami, they're use case competitors. Often when building Drupal alternatives there's a tendency to start "shopping" in contrib for features, adding them on, then stitching them together with a theme, declaring it superior because it's more extensible.

Tsunami gives us a chance to flex Drupal's conceptual muscles rather than simple showing off how shiny 7000+ modules can be.

Competition

eigentor's picture

I guess I second Boris in these personas being most important. We are targeting people that install Drupal and want to get to something with it as quickly as possible while having zero knowledge. For those are the typical Wordpress, wait, the competition in this case is rather Buddypress -Users.

But for an End User it does not matter in my eyes if he uses Ning or Drupal, I mean if he uses a hosted service or builds his own. Well he will know the difference and will know that building your own means more work but gets more control. But it does not matter to him as he expects the build your own solution to be just as easy as Tumblr at leas for initial setup and writing your first post and adding your first image. From Download to install with no pain.

If you get people past this step, they will be willing to examine more and appreciate the additional control and flexibility they have with Drupal. I have seen completely non-technical people go nuts when they find out that stuff like Ning totally sucks when you want features that are just not there. And then you feel trapped because you invested quite some time and quite some people are subscribed to your site you fear losing if you would change to another solution.
But before the install you have to compete with everything. And we all know just how easy for the end user many of these services have gotten. Still I second eaton that this does not mean a lot of features. Does Tumblr have a lot of features? I guess its popularity is rather based on the lack thereof.

Life is a journey, not a destination

I updated my first stab at

rickvug's picture

I updated my first stab at some personas with a some explanation: http://groups.drupal.org/node/128369. I agree that Tsunami should be social. Community/group sites are a common use case for Drupal and play to its traditional strengths.

With this said, I see a key difference between a Drupal site and something like Google Groups and Basecamp. A Drupal site is suitable as a home page for an organization and is likely to grow. Let's highlight this and design navigation and the structure of the home page for this use case. Typical navigation would include things like "Contact" and "About".

Group + Social

eaton's picture

Interesting, I think you're hitting on something very important. There are a lot of easy turnkey tools out there for social sites, as well as turnkey tools for group collaboration. There aren't a lot of tools that cover both -- group collaboration with public-facing engagement. That combined purpose is where Drupal's social options, its permissions system, and several of its built in modules like Forum really shine. They may not be best in breed as stand-alone features, but they combine to form a nice 'group + the world' mix.

(Again, I want to emphasize for anyone reading this that the idea is not to create the one and only true Drupal install, just to create one that is useful and shows off some of Drupal's core strengths without requiring contrib modules.)

As you said, this meshes very well with the user personas that you've outlined. Tom the Site Builder -- if he uses Tsunami -- will basically install Drupal, choose the Tsunami profile, set up user accounts for members of the group, and probably edit the "dummy" pages like About Us and so on. While Tom will almost certainly want to add additional contrib modules in the future, the assumption is that if their group's use case matches Tsunami's use case, he will not need to build anything more to make it useful. It'll just be ready to use. Tom is probably already a technically savvy member of the group already

Suzy, the content editor and site administrator, is probably a member of the group like Tom, but she's the one who manages most of the pages on the site, ensures that there are no spam comments on the public messages, and so on.

Martin, the end-user, is the one that I think might need some thought. Referring to him as an "end user" seems to create an artificial distinction between members of the group and those who are seeking information about it. Would it make sense to distinguish between 'group participants who use the site for communication with the rest of the group,' and 'newcomers seeking information about the group?' For sites that are being self-managed by small groups, I think that distinction might be more critical than "content editor" and "user", even if those terms are more familiar to us from a permissioning standpoint.

I especially like the inclusion of Jane as an anti-persona and Tarun as someone who could learn from Tsunami but isn't expected to use it as a starting point. Those really help clarify things.

Less building

Boris Mann's picture

I still have issues with site builder. I know we need someone to install this thing, but the mindset / label of "building" isn't what I think we should be stressing. It's admin'ing (as you label what he is doing) rather than building.

So, I think of Suzy as fulfilling the main role in figuring out how to evolve the site. Let's also think of at least one other person, either leaning in the Tom direction and being more technical, or a mini-Suzy, someone who has evolved from being a group member and now wants to help manage more directly. Those edge cases, or learning curves moving from one role to another, are where I think we can smooth the experience.

If we go with public / members only mix, then use, we have group members vs. site visitors. One of the main use cases for a site visitor might be signing up to the group and becoming a member, and we definitely want to focus on having a great experience there.

Good distinction. We've

eaton's picture

Good distinction.

We've gotten used to the idea that "building out the site" is ground zero of using Drupal. I like the idea of separating out the persona's responsibility of setting up the site and shepherding its ongoing evolution. You mentioned on Twitter that you'd "love to leave "holes" in the core profile that are nicely filled by contrib modules - e.g. mailing list" and I think that's a great way to turn Tsunami into a "gateway drug" for more complex site building.

We can't point people to individual contrib modules from the profile itself (because we can't know that those modules would remain active during the entire core life cycle.) We could, however, maintain a page on d.o. with an overview of modules that make great add-ons to Tsunami, with some brief instructions on how to set them up with the role/structure defaults that Tsunami provides.

Gateway drug for sure

Boris Mann's picture

And have that page be a jumping off point for resources in the d.o. ecosystem - hosting, finding a developer, theming, industry specific g.d.o groups, regional g.d.o. meetups, etc. etc. etc.

Yes, you exactly got what I was aiming for with the holes. You discover the hole, look around, figure out how to do an install, and all of a sudden you've leveled up without hitting the learning cliff.

I agree that the we need to

rickvug's picture

I agree that the we need to define the nomenclature here to keep things clear. There are many "end users". "Site builder" is a tough one. What we are really talking about is the person who installs Drupal. This person isn't building a site as much as filling in information and tweaking settings as needed. This is similar to most other software products. I typically think of a site builder as someone mucking with fields and Views but where do you draw this line? What is someone who enables modules and configures block placements?

Yep

Boris Mann's picture

Totally agree. Blend of public facing and "internal" collaboration.

I actually think there might very well be a single option on whether this is a "private, login only" site vs. a "public site with members only content". Not to say that it can't transform easily from one into the other.

Thinking more about this -- "Tsunami - your home on the web" has a pretty damn nice ring to it.

Ha!

eigentor's picture

This is interesting.
Drupal holds a sweet spot that is very useful - and we never noticed or rather never marketed well enough.
There are lots of one-off solutions for internal communication and as well for outward-facing presentation of a small company or initiative.

But combining both with ease in a base install without hardly any additional extensions needed - this is Drupal!
Heck. Gonna print stickers and make a bat-beam into the night sky.

In our business we notice that we do lots and lots of small brochure-ware sites with nothing much more than products, about us and a contact form. This makes me believe this is a big market.

Life is a journey, not a destination

Pick one persona

leisareichelt's picture

I'm not sure about you but my experience of personas is that the more there are, the less they're used. Combine that with our desperate need for clear constraints on this project and the Drupal community's natural tendency to be inclusive (that is, to consider and design for every possible use case)... I really think we should choose just one persona. Choose one and then build them out - based on real data/experiences that many of us can contribute - make them so realistic and help the whole community know and understand them. And use that one persona to guide all the design decision making. 

Otherwise I think you'll find the personas useless for anything more than facilitating a rough discussion re target audience here - and they can be so much more powerful than that. 

Which persona to choose? This comes back to Drupal and I'd suggest it should be driven by two criteria: feasibility and impact.

Based on a rough understanding of what each persona needs - which is more feasible from a development perspective. The more feasible, the more we like them. Secondly, if we get it right, which will have the biggest impact on achieving the goal of increasing the number of people who use Drupal to drive their web stuff. We can potentially give each a score out of ten and see which wins. 

Combine a single persona with a single (or at least very limited) purpose / set of functionality and we're in a great position not only to design /build but also to evangelise the importance of this project and explain how it works. 

leisa reichelt - disambiguity.com
@leisa

Glad you're here Leisa!

rickvug's picture

This is very constructive. Perhaps a way to structure this would be for the single persona to be involved in both the initial setup and day to day running of a site. This is actually quite a realistic scenario for the target market of a Drupal product.

An example would be a father coaching his daughter's football team. He doesn't know where to start but he's heard that Drupal is the right tool for the job. He installs Drupal and by answering a few simple questions during installation he has a working site. After data entry he tells the team about it and the site's a hit. He starts enabling new features and adding fellow parents to help keep the content fresh. The parents are given the capability to upload their photos and blog about the latest games. They use the forums to arrange carpools, swap gear and organize the team picnic. The aggregator pulls in the latest updates from the league they participate in (and so on...)

Leisa and others: what is your take on a direction like this? Any persona writing tips? The focus on the paragraph above is on the actions being taken rather than the caricature that we'd be developing for. Hopefully this verifies that developing for such a persona is realistic.

Community Owner

Boris Mann's picture

That is exactly what I was thinking of when I said "community owner". There might be the actual "owner" who is less technical but admins the site, or the more technical person that "owns" the community because they've figured out the tool and set it up.

The persona and the use case(s)

leisareichelt's picture

OK, so I think this is a great target market to pursue. I think there are a couple of things we need to do here - define the persona, and then define the use case and associated tasks/functionality - we need to make sure we don't confuse the two.

When we're thinking about the persona we need to consider: what are the important behavioural characteristics that differentiate this persona from others that would also use Drupal. So, the kinds of things we'd be looking at are, perhaps:

  • technical proficiency - does this persona have any familiarity with code at all? if so, what/how much
  • mental model - does this persona have any concept of how a content management system works/is structured? if they were going to describe how a photo goes from their computer onto the web, how might they describe it?
  • what other software are they most likely to be familiar with (what conventions will they be drawing from?)
  • what kind of support networks/infrastructure might they be familiar with? what would they typically do to get help with technology problems?
  • how much time do they spend on the computer every day? how much time would they be able/willing to commit to Drupal (to manage the team website) each day/week?
  • how much time would they be willing to put into getting this website set up? (are they doing this on the weekend/at night? are their lots of interruptions? will they be able to do it in one sitting or multiple sittings)
  • what about design sensibilities? do they have any? what's important to them?
  • do they use mobile internet? have an iPad?
  • do they consider themselves a bit of a technology expert amongst their non-techy friends or are they really not very comfortable with their technical competency (confident or not confident as a starting point?)
  • do they just want to get something set up quickly that does enough (satisficing) or are they really going to get into this and want to add lots of bells and whistles - keep improving it in coming weeks/months.
  • would they have a clue how to register a domain name? (or what a domain name is?)

so - these are the kinds of questions that we want to start trying to define - getting a sense of who this guy is in terms of what's important to us (technical proficiency, time allowances, confidence level and objectives for the site - probably more, feel free to add)

then we need to look at the use case which to me sounds like a fairly entry level community website where a group of invited members can share content on a website (public? closed?)

I like this because it strikes me that this is a surprisingly underserved area (although someone could probably do a competitive analysis to confirm that - would be a good idea, if anyone is keen?), and because it's the kind of thing that could be used for anything from sports teams to church groups to bookclubs to people sharing baby pictures, to neighbourhood watch committees and beyond. It also really suits being given an MVP (minimum viable product) outline that we can aim for to begin with and then layer in more detail/functionality/complexity later on.

it does also indicate that it is a targeted at a non-commercial audience, which is also something important to note (bearing in mind, of course, that it could just as easily be coopted for commercial purposes
by end users who wanted to do this).

So, from my perspective, there are three next steps:

  1. define the persona further. Actually turn it into a proper persona with a picture, a real name and all of this behavioural/attitudinal information into a format that we can show/share/remember.
    There's a nice template here we can use: http://zakiwarfel.com/dl/Persona_Template.pdf

  2. confirm the use case

  3. define a list of tasks/activities for the persona based on the use case/their behaviour.

Happy to do a draft of a persona if you like unless someone else fancies taking a shot at it? (I'm pretty swamped with work so might take me a day or two).

@eaton - does this all still sound like Tsunami to you?

leisa reichelt - disambiguity.com
@leisa

Hooray!

eaton's picture

Leisa, thanks for coming in to share this. I've been swamped with pre-Drupalcon stuff as well, but this definitely feels like the right direction. Three points in particular really stand out:

how much time would they be willing to put into getting this website set up? (are they doing this on the weekend/at night? are their lots of interruptions? will they be able to do it in one sitting or multiple sittings)

This is a huge one that I think is often completely ignored because we focus so much on the building process. Ideally, if the database is in place and there are no hitches on the server side, it should be possible to go from "I uploaded Drupal onto my web server" to "The other people in my group can log in and post stuff, and I wouldn't be embarrassed to show someone" in an afternoon or evening. That would include entering some basic "about us" content and adding the members.

then we need to look at the use case which to me sounds like a fairly entry level community website where a group of invited members can share content on a website (public? closed?)

I'd say it's a public-only site at the moment. In Drupal Core itself, implementing members-only sections is definitely a challenge, so it's best to sidestep it unless we can think of a compelling, useful core patch that would give us that functionality without colliding with other contrib modules. That's one of the reasons I emphasized the outward-facing nature of the group's efforts rather than just the internal communication. I might be muddying the waters, but that story feels like it nails what drupal can do better than a site that would need a lot of private in-group communication.

I like this because it strikes me that this is a surprisingly underserved area.... It also really suits being given an MVP (minimum viable product) outline that we can aim for to begin with and then layer in more detail/functionality/complexity later on.

Agreed, wholeheartedly. In looking around most of the tools focus either on creating visually-focused static sites, blogging-style publishing, or pure social connection/sharing (aka Ning). I'd really love to come up with a list of example group that would fall under this general description. Is there a way to capture "organizational personas" in addition to the specific "user personas"? Would that even make sense?

I absolutely think that what you're talking about is 'Tsunami.' My biggest concern is that we be able to keep the focus on the kind of "group story" that would guide the organization/club/team/etc using the site in addition to the primary user who we're talking about performing the tasks. I think that can help us avoid drifting, and can also keep us on track with descriptions of why the tool is useful. Thoughts?

Group stories + moving fwd

leisareichelt's picture

Great!

So, I like the idea of creating a list of scenarios of use - different types of groups, why/how they'd use Tsunami, what their key criteria for choosing a system would be (although now I wonder whether it is more typical that our persona just takes it on himself to sort it out and the group are just delighted? - thoughts). I'd rather not call these personas - it's a troubled enough term/concept as it is so let's try to keep it relatively pure.

So, next step: I'll take a run at a draft of our detailed persona ETA Drupalcon, unless anyone can do it sooner?

leisa reichelt - disambiguity.com
@leisa

This scenario sounds like it

Mojah's picture

This scenario sounds like it is more to do with one person wearing many hats. Although valid and true for the majority of folk who download and use Drupal, it may help if the persona was created with the understanding that they would only wear just one hat. That way, it would be easier to focus on what functions this type of persona would perform and how they would interact with the site during it's life.

Using the example above we could create 3 types of personas:

Coach: The people who are involved in configuring the site. They plan, create the vision, objectives et. all and eventually click the install button and then configure the features based on their plan
Partner: The people who actually "own" the site and take a greater responsibility for it's continuity. They create content, moderate, promote etc.
Player: The folk who use and inter-act with the site. They add content, post on the forums, comment...

By clarifying types of personas we can then define how each persona type will interact with the application - in a more focused or organized way (This helps big time when defining permissions later on!). It doesn't matter, at least not during the development of the application, if the end user takes a role in more than one type of persona.

The personas in the previous post (Tom, Suzy, Martin et. al.) would be end users wearing many hats. They would be coaches, partners and players.

Developing the character helps! It helps with creativity and would bringing real life people into and situations into the project. We always develop the characters of our personas, right down to the color of their dogs...and what time they go out for walks ;p

Real life examples

rickvug's picture

...one thing to add is that I'm not tied to the football team example. There are many examples that could be used. At the last agency I worked with we'd get calls from community groups and small business nearly every day. They didn't have any money but wanted to know where to turn. I would have loved to have pointed them to Drupal.org with confidence that they'd have a site up and running soon after. I think we all have stories about these scenarios.

every day business

eigentor's picture

Would not hurt if it comes in handy for our daily business, too :P
Hard to say, but probably these kinds of job resemble each other much more than the "bigger" projects, that tend to be very diverse.

Life is a journey, not a destination

Rick, I think the football

eaton's picture

Rick, I think the football team was a great example. We're talking about a key user persona for the actual focus of the profile itself, but I think it would be really valuable to have a short list of groups and organizations that would be served well be the functionality we're describing.

OSS software teams that want a 'home base' for their project outside of github? Local knitting groups? Sports teams? School departments that want to publish information about their research? Groups of people inside a large company that need to put up an internal site for a team that's working on a particular project? Volunteer organizations launching a project in a particular neighborhood?

I think (perhaps?) this would be good to separate from the user persona that we focus on.

clarity appreciated

eigentor's picture

So this would need datamining - raise statistics.
But this also needs a decision which persona is most important to us.
And Persona and use case are two different things again, so ideally we constrain to one persona and one use case.
Uh, clear boundaries. You are right, this does feel strange.

A clear thumbs up to eaton, by the way: start with one clear persona and use case and do it really well. If no more comes, pity. But down with mishmash plumbing.

Life is a journey, not a destination

Target Audience and Use Cases

gdzine's picture

I am interested and gone through the discussions of this group, and would like to opine my view unbiased.
Please forgive me if I have misinterpreted your ideas. But i do hope that my post will help us all for our common goal -snowman.

According to me when we are talking about a installation Profile persona should be Site Builder because for any damn site you can easily classify three persona
- Stake Holder / Promoter
- Builder /Developer
- User/ End User

In case of Snowman Installation profile we have answered our question of Which Persona? Builder/Developer/Promoter him/herself but not user/End User.

Now question comes in mind what kind of site to be built by SnowMan? So we need Use cases/ Case Study we are going to cater by SnowMan or are we thinking in line of various different Use-Cases catered by SnowMan as options to choose from?

~~~~~~~~~~: http://gdzine.net | http://twitter.com/gdzinenet |info@gdzine.net :~~~~~~~~~~

Snowman

Group organizers

Group categories

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: