planet drupal · strategic ux

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 to put the download button back on the homepage.

One of the things we were least happy with in our process for the 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]

30 thoughts on “Drupal7 Experience Strategy & Goals

  1. Hi Leisa

    1. Dodgy link alert.
    2. Strategies need measurement – will you set something measurable around your top 3 points to see how well you’ve done?
    3. The goals don’t seem all that relevant to an outsider, or to express an end “completion point” of your strategy.

    But, a lot of this is semantics.
    I watch with interest!


  2. These look great to me. One question though ;)

    The Drupal community traditionally has a hard time deciding who an end user is, i.e.:

    #1 Downloads Drupal as a web application framework to get a job done.

    #2 Downloads Drupal to build their personal site with it.

    #3 Administers a Drupal site which has already been built.

    #4 Edits/moderates content on a Drupal site.

    #5 Visits a Drupal site (with various levels of interaction).

    [insert more here] – obviously many people are combinations of these personas on the same or different sites.

    One of our biggest issues with the core administration interface is that depending on which site you end up building, different bits of it are exposed to potentially all or none of these people. At usability testing we’ve focused mainly on #2 and #3 – since they usually have to do all the tasks that #4 and #5 have to do as well.

    It’d be really interesting to know if/how you’ve defined end user yourselves.

  3. Drupal does a lot of things. Which easy things do you tackle first? Which hard things do you tackle first?

    Creating content is actually a hard thing that needs to be brain dead simple. So that leads you down the path of intelligent defaults (article vs. story anyone?) and making adding fields do-able and other solutions people more qualified than I will come up with.

    Perhaps a better pithy statement would be “make important things easy and make complex things do-able.”

    A debate about what in Drupal is actually the most important might be a much better foundation for usability work than the community’s tendency to want to be all things to all people.

  4. I think there are 2 extremes in CMS world. One the one side you have plone, where everything is technically perfect but barely any non-enterprise can or should use it … on the other hand you have WordPress.

    I feel Drupal is in between them, with Joomla being in between Drupal and WordPress. Now, we need to decide what we want the future of drupal to be.

    I feel if we only listen to developers, we will be moving more towards plone than wordpress, whereas I would for Drupal to be more popular than WordPress, while retaining its ability to create awesome enterprise websites.

  5. Hard things are always do-able; otherwise they would be impossible. The aim should perhaps be to make the hard things APPEAR to be do-able.

    On a related note, I loathe the term ‘do-able’; achievable is much better.

  6. I find it useful to state an example of what this would look like. In Drupal 6, there is a new Calendar module setup wizard that creates a content type like an event, creates the calednar view, calendar block and and an upcoming dates block. This takes a complex item and makes it easy using reasonable defaults while still allowing for all the tweaking you may need.

    I would love to see more of this in all of Drupal UX. For example with cck and perhaps views in core we could have site templates do the same thing as the date wizard I mention above. It could be in the install wizard. You could choose I want a:
    – blog site
    – news site
    – magazine site
    – organization site
    – etc……

    Then the installer can create needed fields and view that are good defaults but still inform the user that these settings can be changed in the UI.

    Then, last put a nice jQuery UX layer on it to save clicks and make it look nice.

    My 2 cents ….

  7. @ghankstef This is part of the whole install profile/patterns/context-spaces concepts. Hopefully with drupal 7 this will make things a bit more unified and accessible to non-programmers. What’s very exciting about patterns is the ability to share your own patterns (cck structures/views/blocks/etc) with other people by having your website run as a server for these “recipies”.

  8. Sorry, but if you compare this “strategy” to the given example of Google Calendar, then this contains _no_ vision or strategy.

    These are just fuzzy terms with no measurement and no distinction.

    A vision/strategy needs hard facts or it’s no strategy and of no help at all.

    If this is the strategy, then I reject it.

  9. @ghankstef – they are planning on splitting the UI into contrib and including the API “configuration framework” into core. Hopefully it will make it in for d7.

  10. As a goal, maybe it helps to focus on the frequency of tasks that are done with Drupal.

    Tasks done most often, like adding and editing content: make them obviously simple.
    Tasks done less often and more complex, like administration: don’t try to simplify too much, aim for productivity. Sometimes a learning curve is needed and fine.

  11. “80% + the end user”

    80% of what? Of all the population? And have to be on the same line?

    But don’t we have totally different needs and abilities? Designing for 80% means that in practice you should be designing for the least capable because they should able to use it too. And they should – on the lowest (or outmost) level of D.

    Thinking the different groups of users as steps from lowest to highest (skin to core):

    Step 0: Visitor to a D-site
    Step 1: End user – edits the content
    Step 2: Administrator – makes changes to the site
    Step 3: Designer – creates sites
    Step 4: Developer – creates functionalities to sites

    First steps have to be really low and kind. You can enter with a wheel chair.

    On ground level it mostly about design, usability, accessibility. Going up from there the meaning of documentation and community grows.

    “Make easy things easy and hard things do-able.”

    Real life experiences might clarify this.

    As a web designer using D6 I spend lots of time to make the site easy to use for the customer. Easy to add content, simple to move things, quick to show and hide things, effortless to modify content.

    It’s hard. Most of my customers don’t know much about computers. Simple needs to be their simple, not my simple. Definetely not nerd simple.

    If they have to find the content to edit from somewhere at admin area, they wont even try. They can get lost and scared if they are taken to different view when editing content. They don’t want to remember things, they just want to use a tool to achieve their goal.

    Well, I doubt this makes any sense. It’s complicated issue – D is deep like a well and atm. i’m somewhat frustrated with it. Venting it.

    Basically i on the same lines with Joop :).

  12. My 2 cents:

    “Make easy things easy and hard things do-able”
    I’d rephrase to: “Make *important* things easy and *secondary* things do-able”

    WordPress offered a successful redesign by focusing on the one all-important task to the end-user (writing posts, in Drupal: managing content) and making the hard-but-important things easy. E.g. single click upgrade through the web interface was IMHO a major feature: it makes the user feel secure that he/she can maintain a website without being a total hacker. I think that this is a winning strategy, but it might of course have major technical implications.

    So maybe another thing to consider at this point would be where the line is drawn in terms of technical overhauls required to implement usability enhancements.

  13. I began using Drupal seriously with version 6, and now the firm I work for has built at least 5 sites with it. The one thing I’d love to see (and that I feel is essential) is a huge emphasis on modules, SORTED BY POPULARITY! This would have helped me quite a bit early on, and in fact I had to buy the new O’Reilly print book just to get sound advice about the best modules in a well-organized format. Since then, I’ve learned to consult the Acquia website and keep tabs on what modules are deemed worthy of inclusion there.

    Everything about the current Module listings on is below par. Not only is there no mechanism for sorting by popularity/rank, but the search feature is shoddy as well. I remember searching for CCK and the first page results were all derivative projects based on CCK. Only on page 2 did the link to the main CCK module page show up.

    As for the actual Drupal interface, I look forward to seeing the feedback you all get on — and providing my own. Good luck!

  14. If install profiles are really the answer to the “which user” question, then IMHO needs to host a few of those options for people.

    That to me is a huge impediment to the initial UX w/drupal. With that solved, I’d say that gterez is right on. Focus on the most important or “heavily used” features.

    As a site admin myself, those are typically content creation and organization. Along those lines is there a way to create install profiles for developers that suggest better content management through Views Bulk Operations?

  15. Too much ambiguity.

    -Design for the 80% (ref: Pareto Principle)
    -Privilege the End User

    I simply don’t know what you mean by either of these strategies. I could guess what you mean, but am not sure.

    The goals are too subjective, dealing with how you personally feel about it, how proud you have become. As others have said, make the goals measurable.


  16. All three goals are nebulous. There is no way to ever know if they have been achieved.

    The gist of the idea is good but they need to be specific. Nobody can read those goals and know what they mean, which means that everyone working on the project will be without guidance and so all you will get is random motion.

    I would suggest something more of this sort:

    1. Make Drupal a joy to use and fun to develop on.
    2. To make Drupal easier to use first extract function from design
    3. Make function embeddable in any css design
    4. Develop Sensible Easily Understood Terminology by survey of newbies
    5. Make it fast and easy to create, modify and extend functionality.

    Maybe we should just go with what worked for Google:

    Build a Drupal that Works for You
    -Fast, visually appealing and joyous to use
    -Drop dead simple to get a site up and running beautifully
    -More than boxes on a screen, each element can be have style
    Easy to share so you can do more in one place

    Designed for a consumer world where not everyone knows how to code their own CMS from scratch
    -Easy customization with ANY CSS layout
    drag and drop the page elements wherever you want them
    -Easy for anyone to set up a news aggregator, blog, store, and social networking site

  17. I’d like to second what gterez said: WordPress hit a homerun with its redesign for 2.7, making content creation and site management much much easier.

    Drupal would go along way to serving less technically-inclined users by foregrounding those same tasks.

  18. In general, I think these goals make sense.

    One question.

    At the top of the page here it says “Privilege the End User.”

    At the top of the page at it says “Privilege the Content Creator.”

    Which strategy are you following?

  19. 1. Your strategy goals seem to repeat the reasons why drupal hired you. So I don’t get new things out of it.

    2. Get rid of the useless default themes. Drupal claims to be professionally developed. But it ships with themes that use table layouts or layouts where main content doesn’t come first. lol.

    3. You can choose if backend and frontend use different themes. Stick to that, developing an underlying code structure that let’s users easily adjust their backend to their needs (see 2 different ways to configure your car). Add an easy to use default theme to that and give instructions for developing further backends, like e.g. having fieldset in tabs instead of list them beneath each other. That would best reflect drupals philosophy being a framework and let beginners and advanced users get most out of it.

    Although drupal seems hard to use, CCK makes a difference to other cms. Clients are happy when I tell them, that I can create input fields adjusted to their needs, minimizing the effort for them to add data.

    4. Improve workflows, e.g. when a module creates a block, then let the user set if and where that block appears right out of the module settings page without having to change to the blocks page.

  20. Leisa, I have a crazy idea. While you are working on the general UX strategy, perhaps you can install a copy of drupal 7 on you local machine and make detailed documentation of one specific UX — how a UX designer learns to use Drupal. See how much of your job can be accomplished with Drupal. Once you have the first hand experience of a real Drupal user, you will start to look the problems from a user’s point of view.

  21. I should start by saying that I’m really pleased that usability is being pushed to the fore, in discussion of both and Drupal. Usability is first and foremost about presenting the user with the functionality we’re proud of and have spent time on developing, in a way that will convince them that it’s worth actually using it and not soldiering on without it. The most functional CMS in the world can still be so unusable that it’s more convenient for new users to stick with Dreamweaver for the time being: that “time being” means we’ve effectively lost them.

    Broadly speaking, I think you can happily leave the goals nebulous – that’s what goals are – but you might want to translate them into three or four SMART targets which give you better indicators of success. It might be good to produce some sample user stories we’d want to cater for, based on the user matrix (but not become a slave to that level of detail right now). Would we want to think of users in terms of experience or motivation – how a user would distinguish themselves – rather than their level of expertise – how the existing community would rate them?

    More specifically, regarding the details of the experience strategy, user matrix etc. mentioned here, I think that this whole process needs more transparency and structure than these blog posts. Coming to it cold, it’s still not clear from the post above whether or not the “experience strategy” is specifically those three bullet points, or the blogpost linked to in a later paragraph. Or is it both? Or is one a summary of the other? What do we point to, when we talk about the components of d7ux? What parts of the strategy relate to the Drupal experience (referred to in the first goal above) and what parts relate to the experience?

    If we want a structured, robust procedure, then we should have dedicated canonical documents which describe it, and clear links between them. It needs to support images bigger than 450px across, like the ability/time diagram, without smashing the page layout, like that diagram does. They need to make sense without YouTube videos, which a lot of people can’t watch at work, or don’t have the time to sit through. Putting them together shouldn’t be allowed to soak up much time but, from the point of view of existing community members wanting to contribute to d7ux, it’ll ironically improve the process’ usability!

  22. There is a reason why Drupal today can be used for building both personal blogs and enterprise websites. The strength is that Drupal is more a set of building blocks then a fully branded tool. I develop and brand each of my Drupal instances for my enterprise clients based on their specific needs and their specific website solution. I could never do that easily with tools like Joomla or WordPress. Why? Either of them is built for that. I strongly believe that Drupal should not be branded the way WordPress or Joomla are. Why? I do not want Joomla or WordPress. If I would, I would stick to them. Does this mean I do not want your work? No, I really do. I will try to explain.

    First let me say this. It makes me sad to hear that you are trying to generalize websites like blogs, social networks and even small business websites. They are all the same to you, it seems. I think you interpret the Pareto principle wrong. It is a fact that they all need different things to make the user experience better or great. It is also my belief that you can for each website solution with success apply the Pareto principle.

    So, here is a suggestion. Why not pick one battle at the time, the Drupal way. Focus on one type of website solution. Take a single user blog for example. Nobody has provided a great solution for this yet. Why? I have an idea why and I might tell you some other time. If you would use an approach like this you would end up with a website solution that resulted in something like:

    – A Drupal profile that refers or downloads all required modules and themes during the installation process. The profiles feature in Drupal might need to be extended a bit for this to work great.

    – An administration theme for that specific website solution.

    – A default end-user theme for that specific website solution.

    – The installation may even contain a different terminology, different user roles, custom settings, default content and a lot more.

    Best of luck!

  23. Strategy
    Eliminating the web developer.

    Making modules more a part of Drupal, then treating them as an unmanageable outer user experience.

    5 year experience
    Drupal helps you create a complex website, without you needing to go into the code.

  24. Very nice shot, Bojhan! I’d revise:

    Eliminate the site builder.

    Provide a fluid user interface and experience for core and contrib modules to properly account for Drupal’s extensibility.

    Drupal allows anyone to create complex websites without developer knowledge.

    *That’s a rock solid experience strategy.*

  25. Any tool with great power has a learning curve and is unwieldy in the hands of a novice.

    Who is Drupal made for? What kinds of users? Clearly it’s not made for my mother to start a blog. That’s what blogger and wordpress are for. There are thousands of easier ways to make certain kinds of webpages.

    Drupal’s power is in its flexibility. So I agree with 2cents. He’s the one making sense here…

  26. Experience Strategy:

    “Make easy things easy and hard things do-able.”

    I believe the first principle is a ripoff from Perl’s design principle. Nothing wrong with that, other than the fact that Drupal is a multifaceted beast with many users, each with a different take on what “easy” and “do-able” mean. In fact, I was psyched to do my first Drupal project for a non-profit customer (for free, to build a portfolio). But, when it came to their expectations for ease of content maintenance, I had to switch to Joomla. In the long run, no matter how cool the functionality, if it is too hard for the end user, it will not be used.

    “Design for the 80%”

    I’ve always liked the 80-20 rule. That’s why I’m a ‘jack-of-all-trades’, I suppose. I learn 80% of a subject easily and move on before it gets too complicated… Unfortunately, a corresponding rule states that ‘the Devil is in the details’. You should verify that, when you decide to go for the 80%, you aren’t going down a dead-end road that makes the 20% extremely difficult!

    “Privilege the End User”

    As I mentioned above, I had to switch from Drupal because the end users did not understand the interface enough to use it. I believe that this is a good goal. Drupal seems like it is where Unix was at one point, where the lunatics controlled the asylum. Like ending programming statements by spelling the word backwards (if…fi), many constructs seemed to be made simply to ensure a barrier to entry. What needs to happen to Drupal is the equivalent to Apple OS X…that is, abstract a pretty and usable front end onto a robust, if unfriendly back end.

    Sorry for the length. Good luck!

  27. Creating content is actually a hard thing that needs to be brain dead simple. So that leads you down the path of intelligent defaults (article vs. story anyone?) and making adding fields do-able and other solutions people more qualified than I will come up with.

Comments are closed.