Continuing the articles in our agile project case study.
The next step in our agile requirements management process is to develop an understanding of our target users. We believe a user-centric design approach is important. The user interface should conform to the way our users think about what they are doing and trying to accomplish. We should minimize the amount that we force our users to think like our software, and maximize the amount that we should force our software to work the way people want it to.
In this article we document some of the thoughts around who are target users are, and how we think about finding patterns in the way that they would approach using our product. This is a micro-example of market definition / segmentation. We’re looking for patterns that provide interesting commonalities. We’ll use this as a foundation for developing personas.
Starting with the classical breakdown of users…
Beginning, Intermediate, and Expert Users
This is the canonical breakdown of users – classification by level of experience with the product. We’ve written before about designing for competent users. And we also wrote an article focused on the need to help people bridge the canyon of pain from beginner to expert user.
All users of our site will start out as beginning users. And when the site first launches, all of our users will be beginners (except maybe some beta testers).
But none of them will stay beginners for long. They will either quickly become intermediate users, or they will stop using the site. Some people will also become expert users. But most of them will stay perpetual intermediates (as Alan Cooper calls them).
Domain Expertise as a Differentiator
We have another interesting dynamic with the site. All users will either be looking for, or promoting articles. Any given exercise will generally be in one of the topics we’ve identified in our scope document. A user can be an expert business analyst and be a beginner in interaction design. Or she can be a skilled product manager who is exploring business process modeling for the first time. Someone might have written hundreds of use cases, but be new to using UML to describe processes.
So we have an odd situation – people can be both experts and beginners at the same time. Everyone has a different pattern of domain expertise. Someone could understand market analysis techniques far better than go-to-market strategies. But in terms of a single set of interactions with the site, the user will be exhibiting one of their domain expertise levels.
So, any given interaction will have some combination : New User / Domain Expert, Intermediate User / Domain Proficient, etc. I don’t believe that domain expertise will affect how we design interactions for someone – it will only affect what the user wants to do.
User Needs: Initial Thoughts
As a first pass or pre-amble to developing user personas, here are some general ideas about articles that someone would want to find in a particular area as a function of their domain expertise in the area. The lists are numbered not to show relative importance, but to make it easier for people to refer to them individually in the discussion of this article.
Beginner
- Find an overview of the area, to understand if it is worth exploring, or to help put the ideas in perspective with what the user already knows.
- Find tutorials on how to do specific things, like “how to write a use case” or “how to faciliate a JAD session.”
- Look for suggestions and reviews of tools that might help them to do work in the space.
- Participate in discussions on good articles.
Proficient
- Look for reviews of tools that might help them to do work in the space.
- Read detailed articles that will serve as refreshers on how to do something, or improve their depth of understanding in a narrow area, like “estimating projects with use case points”
- Share articles that would help beginners get up to speed – this is the bootstrap approach (you’ve learned it recently, you’re better positioned than an expert to help someone else learn it).
- Share articles that are good additions to the toobox in a domain for other proficient users.
- Participate in discussions on good articles.
Expert
- Look for thought-leadership articles that combine or extend ideas in novel ways, like “goal driven documentation” or “combining interaction design and structured requirements” or “combining pairwise testing with use case scenario analysis.”
- Promote articles that you have published elsewhere for community review.
- Share articles with beginners and proficient users that you know to be very good – this is the ‘stamp of approval’ model.
- Participate in discussions on good articles.
- Create tutorials / lists / links that combine multiple good articles into informal “learning packets” that mix the best content from multiple authors on a single topic.
How You Can Help
Care to validate, refute or extend any of the lists above? Or suggest better ways to look for patterns in behavior or to organize users?
I like to think of where the users are when they use the product. I’d include in their office, in their home, on their way from A to B, on vacation (uh, that’s almost everywhere).
Somewhat off the personas topic: I’m wondering what an ‘article’ is. Does it have characteristics? Is it just some piece of knowledge (I’d say: yes), or even just a reference to a piece of knowledge?
Is it important that an article is readily accessible from the site (that would exclude training courses, books, …)? My answer: no, even a hint for a good book or a reputed company would be of help to the personas.
Wow, great comments, thanks! Starting with the second one about “articles.”
Up until now, I’ve been thinking about it solely as collections of (immediately) consumable articles. From a “how do I write at Tyner Blain?” perspective, I believe the best articles are single topic. But that isn’t always true, and is definitely just my opinion.
There are a lot of great references that are not consumable articles:
And probably others too. And all of this stuff is important to all of us who will be using the site.
I’m inclined to treat them differently, because people will look for each for different reasons (I want a to read about X, I want training for Y). I think we could absolutely leverage some of the functionality we will likely build to make it easy for people to “find great books in our niche” etc.
Do you think it would be effective to present these as top-level activities: “find a book”, “find an outsourcer”, etc, and ask people to prioritize them? I personally want to do articles first, and then add whatever is most-valued second [ed: this assumes that articles is of more value than the others]. But if one of the other areas dwarfs articles in terms of what people want, then we will reconsider.
At some level, this is like the start of Amazon. Bezos’ team proposed “al l things” in a big vision of what Amazon would ultimately become, and Bezos played the dictator card and said “let’s start with books.” Then they added the other stuff later, once they established critical mass and credibility.
I’m essentially proposing that “articles” is the right place to start, and we should add others as the community evolves. But I’m happy to be encouraged to rethink that.
What makes an article suitable introductory material versus deep critical thinking for experts?
Will authors pick? Will readers rate it?With the staff at TB assess it?
I think readers have to rate it. Maybe the person who initially posts the article (to the ratings site) suggests where they think it belongs. Different people will have different opinions on how to classify it. I think there’s a way to show that effectively, and will look at some design options for presenting that.
But Tyner Blain will definitely not rate it in an autocratic sense. Once the site is up, I expect to be a user, not super-user. I like the way Kevin Rose approached things at digg. He was just another digger.
No objections towards starting with articles at all. This is the internet age.
Reading your reply, Scott, I just realized that “find a book”, “find an outsourcer”, “find a great site”, etc. are solutions to the problem “I want to gain knowledge”.
Cool.
First, I’m loving the idea of blogging your agile journey for this project! I’m looking forward to reading along.
On the topic of what an ‘article’ is … I agree that you probably need to pick one type of information source first (like articles) and then move on to the other ones in your list (like books or training). However, I quibble with this comment you made:
>> I’m inclined to treat them differently, because people will look for each for different reasons (I want a to read about X, I want training for Y).
Hmm – second part of my comment got cut off .. so to continue,
I don’t think you are always searching different sources for different reasons. I often find myself doing research when I am having some problem at work and need ideas for solutions. For example, perhaps my projects are suffering because of poor estimations. I’m looking for a solution to that problem, and early in my searching I’m open to whether that solution might be an article, a book, training, a product or whatever.
Keeping this kind of broader problem definition in mind might evolve your user story from “I want to read about X” to “I want to find out information about X”
Hey Chloe, thanks for joining in the discussion!
You make a REALLY good point about user goals. The statement you quibbled with is almost a description of the solution – where the goal is to gain information. I’ll definitely keep that in the front of my mind when incorporating different types of information sources – maybe books and other things will get combined with the articles.
Thanks!
ps: And thanks for the encouragement!