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]

Drupal.org redesign – why is it so? Some insights into our design strategies.

Drupal Redesign V10

Over the past few days I’ve been posting a lot in the Drupal Groups at Drupal.org about the rationale for some of the design decisions we have taken on the Drupal.org redesign. I thought you might find them interesting, so I’ll copy them over here as well.

In particular we’re talking about why the header is so big, the global navigation is so small, search is so prominent, the ‘dashboard’ tabs are more prominent than the global header and why there is no ‘download now’ link on the homepage.

I can’t guarantee that the rationale is entirely holeproof, however it has definitely been based on paying close attention to what a broad range of people want to do on Drupal.org, making some decisions around how to best prioritise these needs, designing to suit these prioritised needs and then testing to check that the new design does actually support key user tasks.

There is one fatal flaw in this version of the redesign and that is that we accidentally left off the big ‘Get Started’ call to action from the homepage… d’uh! (Definitely one of the downsides of designing at speed to fit into weekly iterations is that these kinds of oversights can happen – thankfully the Drupal community let us know about it quick smart!)

You can see the interactive prototype here and the historical archive of the past 10 iterations here.

This is directly copied from my forum posts so hopefully make sense in this context… be warned… it’s long!

Post One: Get Started and the Download Button

evaluating a website design is a really difficult task, as the discussion here and elsewhere demonstrates. It is tremendously difficult to see the design from perspectives other than your own and to get some kind of distance from the content. It is also really hard to judge how well a design works from just looking at it and meandering through it – it can really only be properly judged ‘in action’ – does it actually let people achieve the tasks they need to achieve. Does it make easy things easy? Does it make difficult things achievable? Does it support the objectives we have for Drupal as an organisation? for Drupal end users? and on and on. This is why we’re trying to get the design out in as many ways as possible to see how it’s doing – both online and in person, amongst ‘insiders’, ‘outsiders’ and another groups we’ve recently started calling ‘mid-siders’.

Disclaimers aside, there are a few things that might help move the conversation forward, hopefully! I’m going to tackle the first one here and some others in posts to follow shortly.

Get Started and the Download Button

you are dead right, the strong call to action for Get Started from the homepage has disappeared and this was an oversight on our part. Expect to see this re-instated on the next iteration and thank you for making us aware of it. We have been focussing a lot more on other ‘internal’ pages and just made a few small changes to the homepage this iteration which resulted in this dropping off. Our bad.

If you’ve been following the redesign you’ll probably have noticed that we actually started with an enormous ‘Download’ button, which then evolved into an enormous ‘Get Started’ button which then evolved into more of a ‘Why Choose Drupal’ section. As Mark said, this is a part of a deliberate strategy on our part to ‘bury’ the download button a little – what we are trying to do is to make sure that they actually know what they are getting into when they ‘download’ Drupal, and to ‘scaffold’ that experience a little.

We want them not to expect it to be completely easy to set up a website using Drupal (not to apply mental models of the hosted blogging services, for example, which seem to be quite strong in people’s minds), and we want them to know that there is both a strong and supportive opensource community and commercial ecosystem that can help them along the learning curve if they need it. And, I’m sure you know this already – a lot of people who are interested in Drupal will need that support. For many people who are evaluating Drupal as a solution, particularly within larger organisations, the last thing they should be doing is downloading Drupal.

So, the people we are primarily designing the homepage for are people who are coming to Drupal.org to consider it as a solution for whatever their requirements are, and who are not particularly experienced developers, or possibly not even particularly experienced with Content Management Systems/Platforms/Frameworks etc. This means that people who do have this experience, who do understand the existing Drupal vocabulary, who do want to evaluate the platform by downloading it and taking a look – these people are going to have to work a little harder to get to what they want and they will have to put up with some fluffy language (like the Legos, although I think the Lego reference is being deleted as I write this… which I think is a bit of a shame actually). But the thing is that this audience is capable of doing that little extra work, and they are also more likely to easily recognise what is so great about Drupal.

So, to summarise,

  • we are deliberately making the download link a little more difficult to find so as to better support the experience of newcomers to Drupal who do not have the ability or time to evaluate the product by downloading it, however;
  • the current iteration is missing a strong call to action to ‘Get Started’. This was a (bad!) oversight on our part and we’ll make sure it gets back in there in the next iteration.

I hope this helps make things a little more understandable. Do let me know if you have any questions that I can answer regarding this. I’m going to post some notes re: the size of the header and the placement/relative size of the global navigation next. If there are other issues you’d like me to address specifically, then let me know.

Post Two: That header is so big and it’s all about search? What the?!

First up, I’d like to acknowledge that yes, that is one big old header. It is bigger than your average header and designing a header that size does mean that you’re going to fit less ‘above the fold’. This may seem like an unusual strategy, but it’s certainly not unique, nor does it imply bad design or usability IF it is being done to support a strong strategic objective.

Hopefully you won’t be surprised to hear that we do have some strategic objectives in having such a big-ass header!

Again, if you have been following the redesign process, you’ll have noticed that the big-ass header is actually a relatively recent introduction to the homepage design, coming as late as iteration 7. Here is the last version before it: http://drupal.markboultondesign.com/visual/iteration6/homepage_notlogged…

1. approachability

Use of white space (or in this case, blue space) is very important to design, as I’m sure you know. Allowing breathing space around elements helps you to more easily review the content on the screen and for the designer to guide your eye from element to element. Mark is much more the expert on this tho, (In face, he’s written a bunch about it that is not directly relevant to this conversation but you might find interesting here: http://alistapart.com/articles/whitespace/ )

When I’ve been observing people using this ‘big ass header’ design, the response has been overwhelmingly positive. People say that it feels calm and approachable and easy. People have compared it to a horizon line. It does seem to create a positive effect. This is great because we are trying to ensure that people aren’t overwhelmed by Drupal, and that they feel positive in their ability to understand and engage with it. Everything that I’ve observed to date has demonstrated that the big-ass header is very helpful in achieving this end.

I can’t overstate how intimidating Drupal can be to novice users, although it may strike you as ridiculous. Alleviating this intimidation without getting in the way of active Drupal users is one of the big challenges for this project and the size of the header is a big part of that.

2. focus on search

As you’ve picked up, one of the reasons that the header is so large is because the search element is so large. As with the header, this is somewhat unconventional, but we’ve done this to support the way that people want to use the Drupal.org website.

I’m going to do a separate post about the size/placement etc. of the global navigation and the rationale for that, but suffice to say that for the majority of users, and especially for regular users of the site, Drupal.org is not a ‘browsing’ site- it is predominently a searching site, and secondarily a place to monitor and engage with activity and conversations.

This makes perfect sense, though, when you think about what people actually come to the site to do.

This is a big part of how we conduct our research. A lot of it is talking, asking people about what tasks they need to do on d.o, watching how they currently perform those tasks (much use of Google, as you’d imagine!), getting them to perform those tasks on the new design.

Invariably, for regular users of Drupal, search was the way that people wanted to get to their content. Many people would just just Google search, when compelled to use our redesigned site, they’d go straight to search. I can’t tell you how many times I’ve had to ask people ‘if you had to use the navigation, which link would you choose?’ when asking them to perform a task. This was true back when the global navigation was much more extensive and prominent, and it remains true today.

It was in response to the strong demand for search that we re-made the header to be so big and search focused.

We did some A/B testing between the more conventional navigation approach and the search-centric approach and the search-centric approach was more successful.

If you’re not convinced I’d encourage you (as I have encouraged the community throughout the project) to do your own research – get people who are regular d.o users to define the tasks they do on d.o and have them ‘do’ the tasks using each of the designs – and see what you find. I’d be really interested to hear the results.

Finally, the size of the search element is a show of faith in the ability of the d.o search to ‘do the job’ in finding the information. Generally speaking, search on sites is rubbish and a conventional positioning carries this expectation of rubbish-ness.

The bold positioning of the search element here says – search is the right option for finding what you’re looking for. Give it a try. (And yes, we have been assured that much work will be done on the search functionality for Drupal.org so that it does deliver on this promise).

3. search ‘furniture’

Some other feedback we’ve received is about the ‘stuff’ that’s around the search field and that it takes up space/wouldn’t be used etc.
I agree that the vast majority of people won’t refine their search on the homepage, nor will they use the ‘most popular’ searches… although these are able to be used, their primary purpose is to give information about the search capabilities of the site and to help people use the search properly.

By showing the ‘filter’ options, what we are telling people (more or less subconsiously) is the types of content that will be shown in the search results and that you are able to filter out types of content. We’re exposing the range of content on the site and providing a hint that the search will be more fully functioned than a typical ‘sitewide search’, and certainly than the current d.o website. (and yes, significantly improved search functionality is on the menu for the implementation of the redesign!)

By showing the ‘popular’ searches what we’re doing is alleviating ‘blank page syndrome’ – what do I search for? They are tiny prompts that are intended to help people formulate a search query, and especially if they are relatively new to Drupal, help to expose what others are looking at.

I could quite happily live without ‘popular’ searches, or replace it with something else, but the ‘filter’ options play an important role and should not be removed. In fact, we intend to add ‘API’ to the list of filters in the next release.

search results

A big part of this strategy is a much improved search results page. We’ve only shown hints of this so far in releases, but the next iteration will hopefully show the enhanced faceted navigation within search results to make it a really powerful and useful tool for locating information on the site.

not everyone searches!

There is an important audience who do NOT search, and they are our newer, less technical/experienced audience. They are the least likely to use the search element, and for that reason, the majority of the ‘index’ or ‘landing’ pages are designed specifically for their needs. Starting with the homepage and through all of the ‘section’ landing pages.

OK. That’s a bit of an overview of the rationale and reasoning.

Post Three: Teeny, (Relatively) Tiny Header

ok. This is the last in my series of three monster posts trying to throw some light on why things are as they are in the Drupal.org redesign.

Before you read this, make sure you’ve read the previous monster post on the big header and search, it’s related.

Several people, on this forum and others, have made note of the fact that global navigation on the current design is relatively understated and certainly not one of the most prominent elements of the design. Absolutely true and, for what it’s worth, entirely intentional.

Why so? Well, a number of reasons.

First and foremost, when we considered what the most important and most frequent user journeys on d.o would be, accessing the landing page for a site ‘section’ was very low on the list. Finding out about Drupal, getting access to specific information, monitoring issues and continuing conversations – these were much more important. None of these important user journeys require global navigation.

For ‘new’ users (outsiders) , we consider the movement from Home to About/Why Choose Drupal and/or Get Started the most important user journey. (granted you can’t tell this from the missing links to these on the current iteration homepage – our bad, and an accidental omission as discussed elsewhere)

for ‘existing’ users (insiders) the primary user journeys are to specific content via search/search results and to monitor content/issues/discussions/news etc. which is done via the dashboard.

Hence the emphasis on the search element and the dashboard element (which for existing users will generally replace the generic homepage and will be highly customisable and focussed on monitoring content of personal interest). And hence the demotion of the generic ‘global’ navigation.

We also know that you guys, once you get involved with Drupal, don’t tend to use the global navigation yourself. You use bookmarks, you use the URL (eg. groups.drupal.org etc.) using the browsers memory – both of these are more efficient than going to the homepage and navigating through a hierarchical navigation structure.

Yes, it does seem like a somewhat unorthodox approach, and contradictory to ‘good usability’, but that’s not necessarily the case either.

There is a lot of evidence that shows that people would really rather NOT use global navigation if they can avoid it. People much prefer to use contextual (in content) links for navigation and local (relevant to that section) navigation to get to where they want to go. Global navigation is usually used only as a last resort (or if someone forces you to use it in a usability test!)

Again, if in doubt I encourage you to conduct your own research. Get people to define a few tasks that they would ‘do’ on d.o then put them in front of this prototype and ask them to do the tasks here, and watch them. very few people will go to the global navigation as their first port of call. In my experience, if they are doing that, it’s because there is important information and links missing from the central content area.

A few authors more eminent than me have written on exactly this behaviour. If you have a moment, take a look and see what their experience has been with global navigation vs. local/contextual navigation and search.

http://www.useit.com/alertbox/20000109.html

http://blogoscoped.com/archive/2004_05_25_index.html

http://www.guuui.com/issues/01_05.php

http://www.uie.com/brainsparks/2005/10/19/global-navigation-not-worthwhile/

hope this makes sense and, as ever, awaiting your feedback.

Outsiders and Insiders – Understanding Drupal.org users

OK, there are two important first steps you need to take when contemplating a design (or, in this case, a redesign) – understanding what the business/organisation wants the design to achieve, and understanding who your audience/customers/users/potential users are, and what they want to achieve, what their goals are.

A really common way to capture this information about users is in the form of personas. The personas can then be referred to throughout the design process to test that what you’re designing is actually the right thing for your end users, and to help you to prioritise functionality and content on the site. Basically, to stop you trying to be all things to all people, which as we know, is the fast track to failure.

Now, I’m the last person to suggest that personas are highly scientific (although some people do work very hard to make them statistically sound) – to me, this is not the best way to spend project time. It is imperative that personas are based on research though – going out and actually meeting a bunch of people who form your target audience, because very often, the personas you need (or, at least, the way you ‘break down’ your audience) is what it might first seem.

The Drupal Community put together some personas a while ago, featuring characters like Mary the Manager, Tim the Tool-User, Wendy the Webmaster and more. As you can probably guess, they are based on the ‘role’ that users are playing in relation to Drupal. At first blush, this seems like a logical way to segment the Drupal audience.

It is an important segmentation but – as I’ve discovered over the past few weeks – I don’t think it’s the most important one. Firstly, as we saw in our survey, and this was supported by what I heard when talking to members of the Drupal community, very many Drupal users work across a range of different roles. They do some developing, some designing, some decisionmaking, some sales… all kinds of things. I don’t know this as a fact, but I’d hazard a guess that the ‘pure’ Drupal developer is actually a minority. Just a guess.

At any rate – it doesn’t really make sense to have Danielle the Designer as a persona we’re designing for because Danielle is much more likely to do some code, some design, some content administration, some dealing with clients. The role based persona doesn’t accurately reflect the kind of people we’re meeting out in Drupal-land.

Proposed segmentation – outsiders and insiders

I think our audience segmentation for Drupal.org should actually be a lot simpler than personas – it’s about ‘outsiders’ and ‘insiders’ and the path that people take from their first encounter with Drupal.

Insiders:

Insiders are those of you who are close to the Drupal community – who know and love Drupal and the people who gather around it. You understand ‘Drupal-speak’, you know who’s who in the zoo, you ‘get’ open source. You’re clued in, and you’re also incredibly important to the ongoing success of Drupal – both through the project work that you’re doing (if you’re an ‘insider’ you’ll know what I mean by ‘project work’, if you’re an outsider, you probably won’t – see, Drupal-speak in action, I’m rapidly being indoctrinated!). Also through the community work that you’re doing – Drupal ‘insiders’ are critical to getting people over the ‘brick wall’ I was talking about in our Experience Strategy, they are the people who help ‘grow others up’, or to educate them in the mysterious ways of Drupal. They’re very important people.

They are most likely to be, but not exclusively, developers. Or, at least, to have written code in a past life. This is why Drupal-speak is very much techy-speak.

Outsiders:

Outsiders don’t know much about Drupal, although they have have installed it and gotten a site (albeit ugly) up and running. They may not know what a module is, although they may have posted on the Drupal forums seeking help. They definitely don’t know about the IRC channel where the insiders live. They are facing a fairly steep learning curve (including learning Drupal-speak!). They haven’t ‘hitched their wagon’ to Drupal – yet. They might get a better offer elsewhere.

Along the engagement pathway:

Some of you will identify as Insiders and some as Outsiders, but very many will fall somewhere along one of the ‘engagement’ pathways I’ve scrawled in the picture above. Some of you know a LOT about Drupal, but you’re not a developer so you don’t feel like you’re a ‘proper’ insider. Some of you are well on your way to becoming an insider, having gotten access to the right tools and – more importantly – the right people! Some of you used to be much more of an insider but have other things on your plate at the moment that have drawn you away a little. Some of you have tried to head down the engagement path, but are being thwarted or scared off.

As we move forward with the redesign, this is the model that I’m suggesting we use to evaluate the work we’re doing – to consider this engagement pathways and to plot some key points along it and to see whether what we’re suggesting is going to support users at each of these points on the pathway.

This way, we avoid designing only for those of us who are loudest (and probably most engaged in the community), and we maintain a focus on the range of experiences we need to support on drupal.org – maintaining focus on what matters – the people who use the site, rather than the technology, or the tools or anything else that needs to be wrangled into a good user experience.

What do you think? Does this make sense to you?

DRAFT: Drupal.org Experience Strategy

The redesign project for Drupal.org will be guided by an experience strategy that will inform our decision making in all aspects of the redesign and which will, we hope, be able to be used as ‘a star to sail our ship by’ (as Jesse James Garrett would say) – as a clear objective to design towards.

What is an experience strategy?

An experience strategy is a clearly articulated touchstone that influences all of the decisions made about technology, features, and interfaces. Whether in the initial design process or as the product develops, such a strategy guides the team and ensures that the customer’s perspective is maintained throughout.

- Subject to Change, Creating great products and services for an uncertain world, Merholz, Schauer, Verba & Wilkens (Adaptive Path) 2008

This is a good example of an experience strategy:

Google Calendar Experience Strategy

How it worked out for Google Calendar:

Google Calendar Stats

(hat tip to Peter Merholz for images)

Experience Strategy for Drupal.org (Work in Progress!)

  • Drupal.org is for anyone who is interested in Drupal (not just developers!)
  • Drupal.org will make building a site you’re proud of as painfree as possible (from deciding to use Drupal through design, development and deployment)
  • Drupal.org is the home of the Drupal community.
  • UPDATED: Drupal.org is the project management and release tool for the Drupal software (thanks Robert Douglass)
  • Drupal.org will support people and companies from their initial experience of the product and community and as they continue to increase their knowledge and experience with Drupal and become more active in the Drupal community.
  • Is a showcase for what can be done with Drupal

What we believe:

  1. Drupal.org is as much (if not more) a social site than a content site
  2. The Drupal Community is as important (if not more) than the Drupal Product
  3. The Drupal product is a market leading CMS solution
  4. The ‘end point’ (goal) is not getting more people to download Drupal, the end point is to get more people to have a Drupal site running that they love (with as little pain as possible)
  5. Anyone can find out what they need to know about Drupal on or from Drupal.org
  6. We must flatten the learning curve – anyone can learn as much as they want to learn about Drupal
  7. Modules are easy to find and evaluate and are an obvious asset to Drupal
  8. People can see/learn and align themselves with Drupal’s (and Open Source) values…
  9. Drupal.org is a living organism and, with the help of the community, will continue to grow and improve.

How this plays out

Drupal Family

Drupal.org has two equally important audiences – people who are new to Drupal and people who are already part of the community.

Drupal.org needs to inspire and educate people who are new to Drupal – the end goal being that they become active participants in the Drupal community who have a Drupal site (or sites!) up and running that they are proud of.

Note: getting people to ‘download’ Drupal is not the end point. If anything, it’s just the beginning.

Drupal.org also needs to be a comfortable and safe home for members of the Drupal community, wherein participants are both able to develop their own skills and experience (grow up), as well as help others on their developmental path (help grow others up).

Things we need to do:

  • be nicer to ‘outsiders’ (non drupal, non developer)
  • encourage people to engage with the community (starting by showing them that it exists!)
  • work at flattening the learning curve
  • get all the right content on the site and keeping it updated
  • show the community in action (without ruining it)
  • make things findable (IA)
  • communicate drupal/opensource values
  • help Drupal users kick ass

Getting past the brick wall

Brick Wall

As one person I’ve interviewed described it: ‘I can get Drupal downloaded and installed and get an ugly blog that I don’t want, but then I hit a brick wall’ – Drupal.org’s job is to help people over that brick wall – to help them get the site they want using Drupal.

Helping Users Kick Ass

Bert Boerland pointed me to this great diagram that Dries posted a while back (inspired by Kathy Sierra) which I think really nails a big part of our strategy.

Drupal Users Kick Ass

So, that’s what we’re thinking.

Over to you now. What do you think of this as an Experience Strategy for Drupal?
Questions? Comments? Suggestions?

(Remember, there are lots of ways you can point us to things you think are important for d.org)