UX Gate: Principles

Be worthy of people's trust
Good design can go a long way to earn the trust of the people who our products. Establishing trust starts with the basics – making sure the interface is efficient, professional and stable. Actions are easily reversed, ads are clearly identified, terminology is consistent, and users are never unhappily surprised.

Simple on the surface, powerful underneath
Our products appear quite simple on the surface but include powerful features that are easily accessible to those users who want them. Our intent is to invite beginners with a great initial experience while also attracting power users whose excitement and expertise will draw others to the product.

Pave the cowpaths
Make decisions based on our observations of actual usage. Where paths are already being formed by behavior, formalize them.

Don't make me think
Keep our products consistent. Avoid introducing new interaction patterns when an existing one will perform the same task except when usability is compromised. Prefer self-evident UI over reading documentation. Optimize for scanning over reading. Realize users don't don't make optimal choices, they make satisfactory ones.

Not "just", but yes, we're looking for a small set of general design principles that helps set the mind for great design to happen. These principles together will be 1 item in a list of 4 or 5 checks that together make up the usability gate for core changes that affect the ui.

Here's a nice, 6 minute explanation of the classic 10 heuristics for good interaction design: http://www.youtube.com/watch?v=hWc0Fd2AS3s
The interesting bit is that some of these are at odds with eachother. Simplicity and error prevention vs. user control and shortcuts for advanced use.

Meaning, design is about trade-offs.

The three principles we want to choose would help us make the Drupal specific design decisions.

Thanks for chiming in Michael. You're right that inconsistent and unfamiliar language in the ui is a big usability issue, it shows up as one of the major stumbling blocks in all core usability tests as well. I did a lot of string rewrites for D7 but there's obviously even more labels, descriptions and page help texts that still need work. Let me know if you want to help get an actionable plan for this off the ground (via my contact form or drop by in IRC in #drupal-usability)

Your Drupalcon sesson proposal looks exciting too! Just to be sure you know about it let me link to Core Context UX: Page & Component library here as well.

We discussed principles and concluded that we really liked the direction of :

Everyone agreed to have this as the design principle
1. Simple on the surface, powerful underneath
Description: needs to be polished
• Prioritize your feature set. Drastically. Put first things first.If you need help prioritizing your features, the UX team can offer suggestions.
• Don't shove things behind an 'Advanced settings' tab though
• Take it from small steps (understanding the concept), to bigger steps (applying it), to that one large step where you discover the limitless possibilites

Other potential design principles:
We went over a number of other principles, we did not agree on them fully yet - some of them overlap with other gate requirements and others might lack actionable points. These will need further discussion:

• Connect the dots – about flow, way finding, knowing where you are and where to go
• Pave the cow paths – follow established paths and patterns
• Aim towards universal design
• Provide clear and succinct description/ help text. Avoid Drupal jargons.

Actionable principles
Bojhan raised a concern whether we should pursue focusing on making each principle fully actionable. Due to the complexity of a principle trying to cover much ground, this might be a though job to do.

What we need to do next?
- Discuss how actionable these principles should be, and how we can make them actionable.
- Agree on some more principles

Other ideas for principles:
- High level concepts
- Simplicity
- Consistency
- User centered
- Actionable / HowTos / Examples
- Glossary for developers
- Simple English <= use the simplest, most basic words.

I have to agree that targeting user roles is a key insight. I see the typical usability problems of Drupal as stemming from two things:

1. Bottom-up design for self-use rather than user-needs driven design. That is, in typical unix fashion, Drupal developers tend to create tools for their own use or solutions to their own problems. Then they release them to everyone else to learn and struggle with. It's kind of a miracle if there's any documentation. Often a user interface is applied, but usually after the feature is coded, and it's just "provide access to this setting somewhere", not designed particularly. It's almost an afterthought - slick enough looking since it uses default Drupal UI widgets, but not necessarily discoverable, intuitive, etc. - something like Linux on the desktop. This is the inverse of what really should happen for good usability: a user need or pain point is identified, a good solution is designed (presumably after brainstorming, testing and refining various options), this is turned into a spec, then delivered to a developer to implement, then what they implemented is tested to ensure it meets the needs of users.

   Solution: look at user needs, and focus development requests on addressing "pain points" for users. Often, though, the kind of complaints that result are unwelcome in issue queues (they may be impolite, or just uninformed, and at any rate are too far removed from the mindset of many maintainers). One way to facilitate this might be a team that exists to collect user feedback (including rants and raves on both core and contrib), then files thoughtful issues with the appropriate maintainers.

2. No clear audience. By trying to be all things to all people, Drupal is in danger of being mediocre at everything. In order to succeed at step #1, clear audiences need to be identified. I don't, on the other hand, think that Drupal can succeed with just a single audience. It's too big, too layered, too multi-faceted.

Personally, I tend to divide Drupal into three layers corresponding to three audiences:

1. Code/API/framework layer, corresponding to core and module developers and fairly hardcore coders building highly customized sites mainly through code, custom modules, hooks, etc.

   For this layer, there really should be a focus on the lowest-level API functionality that provides a foundation for all the rest. This should focus on code, not on UI. The core API should be stripped of most anything that can easily be built on top of it - it should just be the fundamental building blocks. It should focus on richness, flexibiltiy, and elegance of code and API interfaces, performance, stability, and security. Increasingly, components in this layer may be provided by components from other libraries (symphony2) so Drupal core maintainers don't have to write/maintain everything directly any more.

   Since Drupal is very developer-driven, I tend to think this layer will "take care of itself". Those writing the code are their own audience here, so we probably don't need much external direction here.

2. Site-builder layer. This does include some API-level code that might be beyond what's in core, but mostly centers around using the UI to build at least moderately complex sites. These types of users are typically fairly experienced web developers. They may or may not be expert PHP programmers, but the key part is that they 'get' the notion of building a site from modular components to provide additional functionality, are comfortable customizing many settings, and understand setting up custom content types then using various means to display portions of that content in various places (Views, Panels, etc.) - one of the strengths of Drupal being that it enables a great deal of this type of thing without needing to write any code.

   For this layer, the focus should be on including nearly everything someone would need to build a highly-customized site without much, if any, coding. Views, for instance, should be a part of this, along with something like Display Suite for layout (which I prefer to Panels, which I consider to be too big, too confusing, etc.) This layer should generally NOT focus on "pre-built solutions" like a complete blog or forum.

3. Installation profiles and "complete solution" modules, corresponding to end-user, small home business, and beginner developers. These are the kind of people who want to "install and run". They don't understand the notion of modules, plug-ins, extensions, etc., and the idea of defining content types, let alone Views, customized templates, Panels, etc. would be way beyond them (at least at first) - not to mention delving into php code. They also don't want to spend all day messing with configuration settings. These people typically want a small, relatively simple site in a defined form: a blog (think WordPress or Tumblr), a forum, an image gallery, a small brochure site, a simple online store (though the latter always introduces the complication of accepting payments).

   The point here is to figure out what the most common needs are, figure out what the most common expectation is for what meets those needs (ie, WordPress as the prototypical "blog", though look at Tumblr too), and figure out how to package that so that it is the easiest-possible install requiring the minimum of configuration to "just work" in the typically expected way, and the necessary configuration options are front-and center with most everything else fairly hidden.

   Here, of course, the focus should be on putting together really-polished installation profiles. Having the option to combine more than one option would be desirable too: a 5-page brochure site with an attached blog, or a blog plus a forum, or forum plus user blogs.

I really think everything is different about these audiences: the approach to "how to customize the system" (code vs fairly intricate UI giving a great deal of control vs ultra-simple UI and "don't customize"), documentation (API references vs how-tos and tutorials vs "virtually none - it's so simple you shouldn't need any"), etc.

I am not sure how best to divvy up responsibilities between these three areas, or to ensure that all "deliver" on time for a new version launch (ie, D8 core/API/framework level is ready, but site-building is 6 months behind and installation profiles are a year behind that. Or would that really be a bad thing?)

But at any rate, I'd like to see Drupal focus on several "audiences", then focus efforts on making Drupal more usable for each audience, perhaps by segregating it into conceptual layers that target each of those audiences.