This usability aims page was initially written as a subsection of a page in April, 2005. http://drupal.org/usability-aims
During the preparation for Drupalcon Boston, Neil, Dries, and I spoke with Jared Spool who challenged the Drupal project to establish two practices to improve our user experience. First, he recommended we need to establish our user experience goals, and second we need to watch our users use Drupal every six weeks.
After the user experience testing at the University of Minnesota, we prepared the presentation for Drupalcon and focused on user experience goals for the Drupal project. They are defined here: http://groups.drupal.org/node/9252
Is it time to update the Drupal usability aims page with the Drupal user experience goals page? Or do we need more discussion?
Comments
Yes
The goals as they are in the draft seem good to me. Just like the Mission and Principles pages, they don't need to be very detailed. Recommendations or good practices would be described somewhere else.
The usability aims from 2005 are more specific and task oriented, while the new goals are more abstract but aimed at any kind of user, which is a good move. And the name change is important: Usability -> User experience.
So the old page could be replaced by the new one IMHO, as the old usability aims are probably a subset of the broader new goals.
I also noticed that "intuitive", which i in the old page, isn't mentioned in the new goals. Of course Consistency, Understandable Language, Not Feel Overwhelming, and Informative Feedback will make Drupal more intuitive, but still...
In principle I agree...
... but I think the wording is not quite there -- although very nearly is.
I strongly believe that these goals should be forward looking, and not retrospective. I made a few changes which I document below to aid discussion and reversion if necessary:
Changed sentence "Research is a good tool to find problems and measure success, but will not directly generate solutions" to "Although research will not directly generate solutions, it finds problems and measures success." to change the focus of the sentence on the important part.
Removed sentence: "Observing users, conducting surveys, and receiving feedback are examples of research techniques which have been used." I believe these goals should be forward looking, not retrospective, and not detail HOW the goals are to be achieved. Publishing HOW, doesn't encourage innovation or adoption of new methods or techniques. The general message and purpose of this sentence is already covered in the preceding paragraph.
Changed sentence "5 human factors central to community evaluation:" to "5 human factors central to evaluating the user experience are:" to be more open and general.
Moved "Drupal provides reusable patterns for many user interface elements." to be part of it's preceding paragraph. It is too small to be on it's own and relates to the preceding paragraph. Alternatively we could remove this sentence.
I also wonder what purpose and meaning this sentence has: "Subjective satisfaction: Allow for user feedback". I didn't change it but wonder if we should pull it?
Bevan/
Bevan/
More Discussion?
Hey,
Is it just me or did I miss all the discussion on this topic? Did it all take place at the user experience testing? All of these user experience goals seem to have been set based on the user? But I never saw discussion about who the user actually is, I have seen lots of Drupal consultants go by say what they think they are, but do their clients actually represent the big amount of drupal users? And for what for type of users do we optimize our interface? All ? (Great if you can do it, but generally not a good idea) As Alan Cooper put it, optimize for the intermediate user, not for the expert nor for the beginner (We see a big amount of users stranding as beginner, but that's solely because most interfaces are optimized for the expert).
I have to disagree with elv here, saying that its good to go more abstract. I consider it never a good idea to go more abstract, unless your talking to people who love to be busy solely theoretical.
The draft, what is its audience?
Should the usability page be a page that communicates the importance of Usability within Drupal to the outside world? Because that will mean that all though the 2005 version needs to be adjusted quite a bit, the format (user,administrator, developer - not sure what the user? is doing here though, missing the designer) is great. You can scan it quickly and you understand what drupal uability is all about. The draft has waaaaaaaay to much jargon to appeal to the outside world.
Or is this a draft to communicate how we will approach usability within drupal? There is a real distinction here between the outside world and,those busy with building drupal modules who will need more information to "get" the principles drupal uses to approach the user experience.
I think that using this draft to communicate usability towards the people within the drupal community is wrong. These principles are great goals, but are they measurable achievable goals? You want to communicate them the problems, not the http://groups.drupal.org/node/9241 list but the big ones, where drupal is failing enormously. You need big elephants to really explain importance of Usability.
Are the principles on the draft for programmers or for people who work on the usability of Drupal? You will probably answer both, but the principles I lined up below I believe do require quite some knowledge. They can probably put way more nicer and understandable but still require quite some investment into understanding and actually applying.
Reduce the knowledge necessary to preform tasks.
Identify the knowledge necessary to preform tasks, find out what the current knowledge is of the user is and finding solutions to fill this gap between the current knowledge and target knowledge (http://www.uie.com/articles/design_intuitive/).
User Experience Culture
Reward good user experience design as you would, good coding. And setup a culture that is aimed at identifying usability problems early in the project, not when the module is almost finished and its really hard to convince the programmer that its really stupid to design in that way. When will we see way more posting on the planet about design mistakes within drupal and design solutions/patterns?
(This way you will also attract al lot more good designers, because when they get rewarded in the same respect and importance as coders they will contribute back. And a more important note on this one, great designers can solve al lot more usability problems within drupal then a usability expert, simply because good design thinking go's a long way)
Mental Model vs. Implementation Model
The way a user likes to do a task (mental model) most of the time is completely different then a application handles the task (Implementation Model). And its for the designers and usability guys important to find out the mental model, before you have the complete picture of the implementation model otherwise we will run into al lot of, you simply cant do it that way (it will piss of the expert). You will always have to work in the constraints of the implementation model, but if you don't understand how a user actually likes to do it, you can never optimize for user experience. You will only optimize for usability, forcing the user into the most usable alternative.
Optimize for ?
Please fill in who is this ?.
Communicating the usability problems from a research kind of level. We have a big application that has the interface being touched by lots of modules so although you can do a lovely eye tracking study, if 80% of the users have a couple modules enabled it completely changes the interface and thereby the value of the study. Usability research goals, do you want to go for formal usability testing with all those funky eye tracking balls or for field research (http://groups.drupal.org/node/11011) and how much do you want to test? Do we test along the process of a beta? (And how will we do this? Please, not to much eye tracking, although invaluable to use as a big elephant it doesn't provide as much solutions as most other usability methods do) - Though most of this should be on another page.
I hope I didn't ask to many questions :). And evl, I think its good they scraped intuitive, its a word that is miss-interpreted so much that its just not applicable any more. And changing to user experience, I don't really see the point? Maybe it appeals more to the drupal community, so then it would be just fine to go with. It's cool to see you talked with Jared Spool he probably is the most well known figure that talks on all of this issues, we should definitely contact him later in the process getting some advice on field research benchmarking stuff.
Response to Bevan (Who posted while I was typing, my short comment)
I totally agree that it shouldn't be retrospective, I am not sure if we should completely leave out how to do user research since it is an important part of communicating usability (Some people really have no clue) maybe not the techniques used but definitely something on the how..
I don't see how people conclude that usability research doesn't directly generate solutions, sure it won't give you an immediate solution for a complex task, but really obvious usability faults I found have a solution presented very quickly.
Your question about "Subjective satisfaction: Allow for user feedback" is very obvious, I think its stated wrongly. What it should be is Allow for easy user feedback. Instead of all that subjective satisfaction stuff.
Best Regards,
Bojhan Somers
I found this very interesting
Bojhan,
I found this very interesting. We've been studying Don Norman's model of interaction in our HCI paper at university which is about this.
The UIE article is also very interesting. A few pieces of gold I took from it that others might also appreciate are quoted below:
Bevan/
Bevan/
Studying current knowledge is hard though
Its really on the basic principles of HCI, although Don Norman's techniques seem to have fallen a bit behind on the time still much of what he says is applicable. Though Don Norman's model shows a designer, which might confuse people over here a bit, here that would probably be equivalent to the programmer.
I will try to go further on the 5 year goal, as that is indeed one of the ways to go with focus on user experience design. However few companies actually mastered this, getting everyone on the same vision. (Apple sure did)
formal usability testing
In terms of 'not providing solutions' - it was made very clear by the usability professionals at UMN that they would not be giving us a list of suggestions of things to change, how to change them etc. - in order to maintain a clear separation between the testing and implementation of any fixes. Now, as we watched participants, we'd be sitting there noting down things we wanted to change (and some changes were made to CCK during the week) - but the onus was on us as developers to do this, rather than have it handed to us by the lab staff. I think that was the reason for putting it in the goals, but out of context I agree it's not all that clear. However I think we need something in there that it's the responsibility of the Drupal community to make changes based on research - rather than usability labs handing us textual changes, mockups etc. on a plate. Since I'd imagine a very, very small minority of Drupal developers have been involved in formal usability testing (March was the first time I'd done any), it probably makes sense to get expectations right - but maybe that needs to be sub-page about formal testing rather than in the aims?
Answers
Thanks for your feedback.
Usability discussions have been going on in Drupal for years, in forums, in the issue queues, in the usability group (http://groups.drupal.org/usability ). This discussion started most recently in our research to get user experience experts to present at Drupalcon. I started a thread to get a conversation about what Drupal's user experience goals would be. It was a private thread, (sorry!), to get some ideas gelling.
At the university of minnesota usability testing, the usability sprinters, spent a couple hours working on a draft of the user experience goals and presented those goals at Drupalcon. Then Bevan posted the goals in a wiki page and they've been waiting for further review and improvement.
We've had audience discussions in the past, and I think aiming for a Drupal administrator, someone who has set out to administer a website is good audience to target. We can break off and chase down a lot of different audiences, for example these d.o. personas but we are early enough in the process to say we are leaning towards an intermediate user.
The audience for the user experience goals should be the Drupal community, particularly the core contributors who are striving to accomplish these user experience goals. They should be aiming to accomplish these goals over the next 5 years, hopefully sooner ;-). It's worth emphasizing, that these user experience goals are for Drupal core, and not for contributed modules. Contributed module developers can choose to align with those goals where it fits their needs.
We've got plenty of lists of improvements to be made: http://groups.drupal.org/node/7314, http://groups.drupal.org/node/10195, http://drupal.org/project/issues/drupal?text=umn+usability&projects=3060...
We can use this document to explain our intentions, and ensure we are consistently striving towards these goals.
I won't address the four goals you outlined yet. I think others in the community should have their say first. But it is important that we strive to get some goals sooner rather than later. We are in the middle of the Drupal 7 development cycle, and it would be good to provide one more tool to help rally the community to improve the user experience of using administering Drupal.
Cheers,
Kieran
Drupal community adventure guide, Acquia Inc.
Drupal events, Drupal.org redesign
User experience Strategy
Audience of Drupal
I have looked over the persona's with a lot of thought, but didn't really understand how webchick came to make these. Although personas are great, I believe that the process of creating personas is the most important one (Its simply where you actually learn the user, rather then guess) . I cant value (and I hope no one can) personas on their description. You pointed out the administer as the primary audience to chase, which to me sounds like a great plan however we do need to know al lot more about this administrator.
Audience of the draft
Oke, so this draft is for the Drupal Community, core contributors in particular. So why not set goals they can achieve? Like evaluation by the usability group before beta release of a core module/interface element. A zero-content page for the core modules that need it. A actual dashboard. Because the principles that are set in this draft, are somewhat vague to begin form. They are great principles, but I doubt a core contributor can just apply them, and with that create a more usable product. Explained below:
Understandable Language.
Comment : don't really see a programmer going, lets use non-understandable language. They just don't know what kind of words the administrator uses vs. what words they would use.
Never use a big word when a small one will do, perfect labels are a myth.
Consistency
Comment : Context over consistency! Consistency is most of the time met in the labelling and very specific interface elements, such as the search box. Maybe its interesting to create a interface pattern library? How do programmers apply consistency if they don't know which parts are the consistent parts of the interface.
What do users expect in an interface interaction? What are there conventions? Joomla or Wordpress.
Not Feel Overwhelming.
Comment : Leave out stuff, and see if it makes a difference on the user experience. You don't have to cater all the programmers needs, just make sure that you facilitate their needs (Even if they say, this is an essential setting). What is overwhelming, cognitive explanation?
User interfaces should be straightforward and concise. Make complex tasks easy and hide, or omit, useless or irrelevant user interface elements. Leave out stuff, and see if it has a positive effect on the user experience (Essentials only)
Informative Feedback.
Comment: How much of this has already been done? Can this principle/goal be less abstract? Like show the result of a task, write help messages for when thing go wrong.
User Experience Strategy
Although I understand the need to pursue these goals, I think that having a 5 year goal is not necessarily something you want to communicate. You want an shared vision of where Drupals experience will be in 5 years. Though you want to communicate achievable goals for Drupal 7, just like we have programming goals for Drupal 7 : the semantic web, we should have this for the design/usability side. Because if we have something like that, we can communicate and test if we achieved these goals when Drupal 7 gets released. Like you said, its better to get some improvements in rather then later after all of this discussion, what tool do you think we should focus on?
I don't really feel comfortable with the term user experience, because to me user experience is the whole process of Drupal which includes downloading available modules (not finding the right modules), the handbooks/forums and the quality of all this. (Jakob Nielsen and Don Norman explain that user experience design "encompasses all aspects of the end-user’s interaction with the company, its services, and its products)
And I hope we are not going to tackle all of these. Where as User experience tries to meet users expectations, usability focuses on simply finding the task, getting the task done and moving on, where desirability to do a task a certain way is slightly touched. And having a successful user experience strategy means that you over-deliver on expectations.
I think in this case its just used as the new buzz word, to describe usability?
The personas webchick made
The personas webchick made for the Drupal.org redesign are personas for Drupal.org website users, not Drupal software users and I think this is an important distinction.
We did some work on testing personas prior to the Minnesota testing but ended up using 'admin' - which I think fits well with Drupal itself - an admin can do everything from installing and configuring modules to posting and editing content, and they often do, so targeting them catches 95% of every other role we could come up with. I also thing it's very, very important to emphasise that a 'user' is someone who uses Drupal software, rather than visitors to a Drupal website which happens to run on that software. Issues which affect admins may also affect visitors (like the node/add form) - but most of this stuff is going to have an indirect effect on that rather than a direct one (unless there's hardly any modifications done at all).
I think bojhan's right that stating this as a 5 year strategy etc.doesn't necessarily help much. SimpleTest has been around for a while but in terms of a publically declared strategy for Drupal core development it's pretty much started with D7 - and the plan is to get as comprehensive test coverage as possible, for D7. Similarly with goals like a 'user interface based on research'- we should be aiming to have formal and informal usability testing of all of core during the Drupal 7 release cycle and some useful qualitative data from that (like the spreadsheet from Minnesota) - and to have major interface changes go through some non-developer reviews in the same way we aim to have code go through non-human testing.
As to user experience vs. usability - when doing usability testing we had users find their way to Drupal.org via the module administration pages, help texts etc. by accident - one not quite realising they were on a different website. So while I think it's important to keep the distinction between the two terms, they're quite wrapped up in each other.
I started making some edits,
I started making some edits, and ended up changing quite a few things - nearly all language tweaks, and mainly trying to make the goal headings more 'goal-like'. Also added a short 'who is a Drupal user?' section since I can see that both being asked frequently, and also being a point of contention. Additionally, I reckon we need to make these as short as possible leading on to more practical details where appropriate - like research going off to a usability testing overview. The existing mission and principles are also very short and this is a good thing IMO - could definitely do with more snipping.
In the absence of public revisions these are a new section in the wiki in case everyone hates the changes - here they are for discussion:
What are these goals for?
These usability goals are for Drupal core development, they may also be useful to contributed module developers.
Who is a Drupal user?
A Drupal user is someone using the Drupal software to set up, configure or maintain a website using Drupal. This includes developers, administrators and content editors. It does not directly include visitors to Drupal websites, since it is the responsibility of the site owner to configure their website appropriately; we aim to assist that process using these principles.
User Experience Goals
A tested user experience based on research
Researching users’ experiences and interactions with Drupal is the best way to identify usability issues. Although research does not provide solutions, it finds problems and measures success.
An intuitive interface
User interfaces should be straightforward and concise. Make complex tasks easy and hide, or omit, useless or irrelevant user interface elements.
A consistent interface
Drupal's user interfaces should be consistent internally and with website user interface conventions in general where appropriate. The results of actions should be predictable and expected. Drupal should provide reusable patterns for many user interface elements.
Clear Language
Terminology should be unambiguous and in plain English. Help text should be relevant and readily accessible.
Informative Feedback
Drupal should give relevant feedback about actions performed via the user interface, to confirm success, provide useful feedback in case of error and guide users through tasks.
So the community can describe the user experience in 5 years
As I indicated previously, the goals will help core contributors to have goals for UX improvements in Drupal. We also want the community to be able to describe what the user experience of using Drupal will be like in the future.
Kieran
Drupal community adventure guide, Acquia Inc.
Drupal events, Drupal.org redesign
These usability goals are
I would certainly like to see any guidelines applied consistently across core and contributions.
The first sentence is a bit redundant. I usually try to avoid overuse of the word "Drupal" since it is assumed.
I think the part about visitors has too many qualifiers. I think a good goal is, "Users should be able to provide good UX to their visitors." This can be achieved with good defaults and flexible tools.
Maybe flip around the second sentence to emphasize what research does do.
The second sentence is a bit tough. It is the whole balancing simplicity and power thing.
Maybe the first sentence could use a comma or three.
This is okay.
Potential rewrite: "Give relevant feedback guiding users through tasks, confirming success and providing useful feedback in case of error."
"Drupal should" is not useful and weakens the idea; "You should do X" vs "Do X." I think accomplishing tasks is the most important thing here so I moved it forward.
OK I've had another crack at
OK I've had another crack at this incorporating Drumm and Bevan's comments:
What are these goals for?
These usability goals are for Drupal core development, they are recommended for contributed module and theme developers.
Who is a Drupal user?
A user is someone using the Drupal software to set up, configure or maintain a website. This includes developers, administrators and content editors. These users should be able to provide good UX to their visitors. This can be achieved with good defaults and flexible tools.
User Experience Goals
A tested user experience based on research
Researching users’ experiences and interactions is the best way to identify usability issues. Research finds problems and measures success, but does not provide solutions.
An intuitive interface
User interfaces should be straightforward and concise. An interface should be as simple as possible, but no simpler.
A consistent interface
Provide consistent user interfaces; reusing elements internally, and from website user interface conventions in general. The results of actions should be predictable and expected.
Clear Language
Terminology should be unambiguous and in plain English. Help text should be relevant and readily accessible.
Informative Feedback
Give relevant feedback guiding users through tasks, confirming success and providing useful feedback in case of error.
I think we are as-good-as
I think we are as-good-as there. There are a few minor tweaks I would make, but aren't really important. I think we all need to have a bit of flexibility in order to reach consensus, since this is quite subjective.
Bevan/
Bevan/
If there's no more updates, I'll publish
Hello, if there's no more objections, I'll go ahead and update /usability-aims to be /user-experience-goals
Cheers,
Kieran
Drupal community adventure guide, Acquia Inc.
Drupal events, Drupal.org redesign
Replies to Bojhan and Catch
Replies to Bojhan:
I think you've pointed out that we have a conflict in the purpose of these goals. Perhaps we need one set of goals fro drupal 7, more specific concrete things. And a different set of goals for usability in Drupal in general, like drupal's mission statement.
These goals were designed with the latter in mind and are still more appropriate.
Replies to Catch:
I'm not sure I agree with this, but I think I'm the odd one out here. In any case, this implies that we need to make it easy to admins to do the task of making their website easy to use, for their visitors. This means we need to make it easy for site visitors in it's default settings.
Can we rephrase this goal to be easier to understand using simpler language?
At uni we've been talking about this with the following concepts. An interface should match the domain of the task -- if the domain is complex, then the interface will be complex (but there should also be knowledge gap fillers). An interface should be as simple as possible, but no simpler -- kind of sums up the above in different terminology.
Other than that phrase seeming disjointed (perhaps it's just me?) this looks great to me! :)
Bevan/
Bevan/