Understanding our Audience (Part 1) – Drupal7 UX Project

We’ve spent quite a bit of time trying to develop a framework to understand and frame the Drupal7 Audience in such a way as we can successfully design for them. We thought you might be interested in seeing some of our thinking to date, so we recorded a quick chat about it in the video above. (I really should do my hair before videoing myself!)

As an overview, here is the outline of what we’re thinking:

There are three important user attributes: role, type of site, and size/complexity of the user ecosystem(number of users in the system and no. of different roles defined).

Important roles:
– end user (define here)
– editor
– site builder
– site administrator

Important site types:
– blog
– news/publishing
– groups
– events

Important ecosystems
– single user
– 2-5 users
– 5-15 users
-more than 15 users
(need to work out a way to define number of user roles as well)

This is still very much work in progress and there is more thinking to be done – stay tuned. Meanwhile, I think we need to come up with a fancy word for our little audience prototype thingy.

[x-posted at http://groups.drupal.org/node/20073]

Drupal7 Experience Strategy & Goals

Experience Strategy:

  • Make easy things easy and hard things do-able.
  • Design for the 80% (ref: Pareto Principle)
  • Privilege the End User

Our Goals:

  • The combination of powerful functionality, amazing community and great user experience should make Mark & I switch from WordPress/Expression Engine to Drupal7 as soon as it is released.
  • We should be so proud of the User Experience for newcomers to Drupal that we need to redesign Drupal.org to put the download button back on the homepage.

One of the things we were least happy with in our process for the Drupal.org redesign project was the experience strategy that we developed and then hardly referenced at all. This was because it was simply too long for anyone to keep in mind – an unwieldy experience strategy, as it turns out, is not much of an experience strategy at all.

With that in mind we have drafted strategy statements and goals which we hope to use as ‘stars to sail our ship by’ on this project.

How do you like them?

[x-posted at http://groups.drupal.org/node/20066]

UX Suggestion Box – Drupal7 UX

Mark at Drupalcon

If you were at the recent Drupalcon in DC you may have seen Mark Boulton and I at the UX Table plying people with jellybeans and requesting offerings to our Drupal7 UX Suggestion Box. This is just one of the ways that we are hoping to engage the Drupal community in this project and to continue that process, you’ll find below the contents of the suggestion box (as of late Friday, unfortunately our desk and all it’s contents was trashed on Friday evening (boo!) so it’s possible we’ve missed a few suggestions).

Please take a moment to look through the very roughly (and quite possibly not entirely well) sorted list below – we’d be very interested to receive more suggestions from you or your comments on the suggestions collected thus far.

There are multiple destinations for the suggestions collected – many of these will feed into our thinking for this project, but there are also a few that will probably be added to the issue queue (if they’re not there already) and a few to add to a wishlist for releases beyond Drupal7 – don’t feel as though you need to censor yourself to only what you think is reasonable to expect for Drupal7 – let us know what you’d like and we’ll see what we can do to help make it happen!

Drupalcon DC UX Suggestion box contents:

Information Architecture (Task Based)

▪    Role/Task/Workflow
⁃    Have ‘packages’ that automatically install common functionality. Talk to Dimitri about install profiles
⁃    CRUD (Create, Read, Update and Delete) admin for specific admin types, terms etc.
⁃    Distinguish between site builders, site managers and site end users
⁃    Better default roles & config
⁃    Workflow improvements to core
▪    ‘Feature based’ administration/ Add ‘features’ then configure content types, views, categories etc. for each one. Everything becomes a feature, some that you can’t disable eg blog, forum, wiki, required ones for example are ‘users’
▪    Bring all options for content types into the same area but also leave the feature config under it’s own admin screen (find either way)
▪    I always use Path to define an alias of “login” for (site)/user. Login as the URL makes sense to people and they can remember it
▪    Get rid of Site Building and Site Config. No one really understands the distinction – you just gt used to where to find what you need but contrib modules are randomly placed. Think about tasks instead


▪    It’d be nice to be easier to install language pack from core to modules (esp. Thai!)
▪    Node create and edit menu settings. The ability to set the weight of a menu item via the (existing) drag and drop interface but inline with the menu settings and node edit form before saving node
▪    Install modules, themes and updates through the UI
▪    In Drupal7 revisions should be allowed to be published in the future
▪    XML querying gate w module info
▪    Disable menu fieldset on content types that don’t need it. Also restrict menu locations
▪    Allow user registration using Open ID
▪    Widgets for user fields
▪    Add data types to CCK fields. This way integers and other data types won’t be sirted as strings
▪    Configurable node admin
▪    Smarty type var handling for themes
▪    After running update.php we land on a sreen with links to front or admin – why not just go to  Front and probably save a click?
▪    WYSIWYG Theme Builder/Editor


▪    Fluid project accessible reorder widget instead of arbitrary drag & drop for menus
▪    Content entry screen improvements
▪    Sorting/Filtering
⁃    Improve the admin/content/node page? I often build a view to replace this page. Clients of mine need: Sort by title/type/etc. (by column), Show last updated date (how about a flexible way to choose columns to display) and created date, search/filter by keyword in the title
⁃    Streamline administering roles & permissions (eg. as an option, allow application of permissions on module config pages)
⁃    Allow configuration of all content type settings on single page as well as existing ‘per content types’ approach. eg comment setting, uploads, etc
⁃    Comment views or CCK for better sorting and control
▪    The date selection shouldn’t just be text
▪    WordPress-like dashboard
▪    Modal dialogs for confirmations
▪    Warn users if they are about to navigate away from an unsaved node or block
▪    Make the UI drag & drop
▪    Increase admin text sizes across the board
▪    Do not get rid of the front end/administration integration
▪    My users want an EDIT button on everything
▪    Smaller /admin page

Search (as in the core search module)

▪    cannot exclude content types – need to, if you have ‘database table’ types that are just used in views but never directly displaced. [I think there’s a contrib module that does this]
▪    need ability to add pages and index them, composite pages like views and panels


▪    Our .gov contracts are v interested in accessibility, particularly in the admin section (since so few CMS platforms have admin accessibility)
▪     Accessibility by default – WCAA 2.0

Additions to Core

▪    Core SSL Support
▪    Bring in token and image API into Core. Should be automatically available not just in separate modules.
▪    Views query builder in core, UI as module (views is a single point of failure, too much risk if there’s another views version lag like w/dg)
▪    Image in core content types
▪    Media and WYSIWYG in Core! OMG!
▪    Bring CCK UI into core to bring further consistency
▪    Views in core!


▪    An easy to navigate learning area. Clearly separated sections: learn Drupal, modules / implement learning
▪    Contextual help
▪    Video tutorials in the help area (see WordPress.tv)

Migration/Back Up/ Export

▪    An export module to make migrating a site to a new server/restored server easier
▪    Build in back up and restore utility for admins
▪    When upgrading an existing site, the site’s existing folder and settings should not be over-written
▪    Migration tools that allow easier moves and domain names eg. filesystem path

Remove and replace all core themes except Garland

x-posted on Drupal Groups

10 Social Skills for Community Designers (things we learned from the drupal.org project)

It was pretty obvious from the outset that we’d need some design and UX skills to get us from one end of the Drupal.org redesign project to the other. It was less obvious how important our ‘social’ skills would be – and unsurprisingly, we learned a lot about good and bad ways to share the design process with a community along the way.

Here’s a few ‘social skills’ we learned:

  1. you need to take responsibility for the way that your community behaves: it’s not in any way productive to associate the way that a community is responding to you by blaming the community or even the individuals in it. If you respond that way you’ll never be able to improve the situation. As with every relationship, the only person you can change is yourself. If you’re getting a bad vibe back, the first thing you should do is check your tone and content – what are you saying? how are you saying it? can YOU improve the way you’re communicating. The onus is on YOU to get it right.
  2. tokenistic involvement is a waste of time: if you don’t really care what the community has to say on a subject, don’t ask them. If you do want their input, take the time to design a way for them to interact with you in a way that gets the best from them. Be creative, put a bit of thought into it. Avoid polls and and use surveys with care – you might feel as though you’re involving the community because you have ‘numbers’, but do you have real involvement. Ask yourself what the community knows that you can benefit from, then consider the best way to help them share that knowledge and experience with you.
  3. ask for specific feedback: if you want to get good feedback from your community, tell them what you want feedback on. We *didn’t* do this much during the Drupal.org redesign – instead I was trying to keep it ‘neutral’ and not influence what and how people gave us feedback – we learned that by asking for specific direction we not only got excellent feedback on the issues we highlighted, but others as well. Without direction the discussion tended to be less helpful and was more likely to get personal (not in a good way!) This will also help you to get feedback on more than just the homepage.
  4. give examples: if you want a particular kind of response from the community, it is important to provide an example for them to follow and really great instructions to participate. For example, when we were doing the ‘crowdsourced wireframing’ I included a picture of one of my not very elegant wireframes so that people had a sense that their submissions didn’t have to look ‘designed’. If there are instructions to participate, make sure these are as clear as possible. Then make them even clearer.
  5. wait… wait… wait… engage! once you post something for feedback, go away and make a snack and do NOT get involved in the conversation immediately. This is probably the most difficult rule to follow and one that Mark and I had to coach each other on (and occasionally police! – step away from the computer!) throughout the project. If you dive in and start responding to the first few comments, what you unintentially do is skew and retard the conversation. Rather than exploring a broad range of issues and allowing key points to gradually evolve, the discussion focusses on whichever points you have responded to, everyone starts to focus on those few issues. The richness of the feedback is lost because you dive into detail too quickly. Rather, wait until at least a half dozen people have posted (or 12hrs has elapsed, whichever is soonest) and see what the trends are in the feedback, then start getting more involved in the conversation.
  6. admit errors quickly: the only exception to the rule above is if you’ve stuffed up. In this circumstance you should admit the mistake quickly so that the conversation doesn’t focus on your error. In one iteration of our redesign we accidentally omitted a very important call to action (I know… how could we?!) As you can imagine, that oversight dominated the feedback we received and by the time we responded (way too late!) things were getting a little frenzied. We should have been keeping a closer eye on the situation and stepped in as soon as we realised our mistake.
  7. don’t go dark, but don’t respond to everything: there is a balance in the correct volume of response that you need to aim for. It is really important that you don’t disappear (even if you get really busy) – the community needs to know that you are there and that you are listening. On the other hand, don’t feel as though you need to respond to every comment that is posted – unless you are only getting a handful of responses. As a rule, aim to respond to trends and issues not individual comments. Feel free to occasionally respond with a simple ‘I’m here and listening, I don’t have the answer yet’.
  8. lead by example: it’s an oldy but a goody – interact with the community in the way that you would like them to interact with you. Be polite and respectful. Others rudeness or bad behaviour is no excuse for you to let loose. It’s up to you to set and maintain the standard of communication you want the community to engage in.
  9. assume good faith: it’s a general rule of interacting with others online, but keep it at front of mind especially when you’re putting your own work out there for review and, therefore, more likely to feel a little defensive. Text is a tricky medium for communication – people might sound like they’re being mean or overly critical or agressive when they’re just not great at communicating (or you’re feeling defensive and read everything as an attack!), or being a little lazy with their words, or created unintentional meaning. Always assume that people are trying to be friendly and constructive and helpful if there is any room for doubt at all. In fact, even when it is evident that they *are* being a little mean, it is often useful to deploy this rule – play dumb and be extra nice. Don’t waste time fighting or being a smart ass, or just being mean, or engaging with others who are. Focus on the task at hand – doing good design.
  10. be a human: I think this is the absolute most important thing – don’t assume a Voice of God, don’t pretend to be infallible or to know everything. Don’t feel as though you have to use very big words all the time. Swear occasionally (if your community is ok with that). Admit that you are nervous (or outright terrified, if that’s the case). All of this is allowed and encouraged. Communities are made up of people, of human beings and you are but one of them. Use your real voice and speak honestly. Be open.