D7UX – Design Principles

As we move through the design process for D7UX, every now and then something pops out that makes us think – ooh, that’s important. We should remember that. We’ve started collecting these things and calling them our Design Principles and we’re going to be using these to guide our decision making as we go.

Here’s what we have so far:

  1. Map Drupal to the User not the User to Drupal – Drupal needs to learn how users work and shape it’s interface (although not it’s architecture!) to match user tasks not the other way around
  2. If I need to do something to progress to the next step in my task, I should *never* have to go to a completely different place to do it. The experience should flow – this pretty much follows on from the first principle.
  3. An admin should look like an admin and a website should look like a website. I should always know where I am and what I’m working with. I should be able to switch between the two clearly/cleanly and easily. (We know from user testing done by the Drupal Usability Group that for people newly encountering Drupal this can cause quite some confusion)
  4. allow customisation but give smart defaults – we’ll allow customisation (of course!) but don’t push all the work to the end user. It’s our job, as designers, to take a stab at the best default settings.
  5. wherever possible, help people make good design/UX decisions as they build their site using Drupal – for example, maybe ask them as they reach for their 6th font if they *really* want to do it and explain the implications, similarly as they create their 16th level of navigation…
  6. you should be abe to get Drupal ‘out of the box’, go through the install process and immediately be able to do all the ‘content creator’ tasks without having to go into a section with a name like config/settings/tools

There may be more as we go along. I’d be interested to hear how you like what we’ve got so far and what others you might suggest.

24 thoughts on “D7UX – Design Principles”

  1. This looks like a sensible list, but I think you’re a bit off base with #3.

    The admin/website dichotomy is an artificial one. There’s nothing inherently logical about going somewhere else to do a subset of tasks related to a web site. That’s the way it’s done on most systems, but that doesn’t make it right.

    Only reason people expect it to be that way is that this-other-system they’ve been using does it this way. And I hardly think “every one else does it” is a valid argument for design decisions.

  2. I think these are great and really touch upon the core UI issues on the back end of Drupal. One additional thing that too often goes unrecognized is the need for clear terminology on the backend. For most people, “Site Building” doesn’t mean much to people and does not make me think of visual elements of the site. The language used needs to make using the back end intuitive, so if someone goes to “Site Building” they know exactly what needs to be there. This will also help developers better organize admin screens they create for modules.

  3. An interesting list, a couple of points I’m sure you’ll have thought about:

    4 – give smart defaults. What constitutes a ‘smart default’ is very much dependent on the type of site. With Drupal being used in so many widely different situations I don’t think an “average” set of settings would make any sense. This is the kind of thing Install profiles should be used for.

    5 – help people make good decisions? heuristics are useful but vary across different types of sites, and best practices develop and change over time. Also, people often use features of Drupal in ways you cannot predict (thanks to the flexibility of the hook system) so any advice being given about a set of options can’t always be guaranteed to be true.

  4. Agreeing with @Mikkel hogh I recently did a very small side project for a local business. The one man shop is ran by a guy that doesn’t check his email and doesn’t use the web.

    Now he has a website and when he wants to change a page on it, he only has to click “edit” and there he is. He doesn’t need to go to “administer” and flip the entire screen around.

    Windows did a lot of things wrong from the get go that we as a IT community are still paying the price for. We also know the story of the qwerty keyboard and we all paying out for that mistake.

    So why continue to persist this mistake?

    Personally I like the ajax-field modules (or whatever its called).
    Want to edit a field? click on it, edit it and bamm! done.

    Yes people should understand that are in “admin” mode and things might be going live on a site, but that’s what a big red banner/overlay or similar item is for.

    Everything else I agree with but #3 goes against why reasoning for choosing Drupal in the first place. I love the “edit in place” functionality

  5. whoa up there – just because admin should look like admin doesn’t mean that it has to be an ‘admin system’ in the same way as we see in lots of other systems (like, say WordPress). We’re just saying that you should know where you are and what you’re doing…. hopefully our approach to achieving this will be clearer when we post some concepts for you to take a look at later today! No admin system in our plans at the moment, I can tell you that much.

    @sebastian, yes, it is a fairly general list that might apply to a whole range of sites – I think that’s a good thing. The point is that there are LOADS of design principles that are pretty common to lots of design problems, but these are ones we think are particularly pertinent to this project.

    @darren, the key is in the term ‘help’ – we don’t want to be the design police for a number of reasons, one of which is that ‘it depends’ is a catchphrase that designers use repeatedly and with good reason – context plays a huge role in determining what is appropriate or not. Having said that, there are a few guidelines that people may not be aware of that we could inform them of when they are doing something that would typically interfere with good design/usability and let them make an informed choice. This would be pretty limited. We don’t want to be the design ‘clippy’ either 🙂

    thanks for your feedback so far, much appreciated.

  6. Two points occur to me as I read point 3:

    1) The definition of “Admin” needs to be distinguished in the context of the role of the user, and what they’re entitled to do. Unfortunately, in Drupal, there’s not a clear line between Admin(istration) and “lesser” roles – like content creators, etc. For instance, Drupal sites can define a role where a user can be a content creator of some significant content, but not be able to define a new table. Others can define new tables, but can’t configure functional modules. And many more variations exist.

    So it’s not clear what constitutes Admin(istration). This makes it hard to enforce #3.

    2) I’m not sure I agree that Admin needs to NOT look like the website. In many cases, when you’re creating Drupal site content, you want to see a preview in the context of the actual page layout that the content will live in. So it would be less-good if you had to do content creation on one page (layout), and preview on another page (layout), then return to the creation layout if you found an error via the preview.

    I _would_ suggest that it’s useful to make sure there is a visual cue that you are in some ‘mode’ that should alert the person that they are involved in some activity that might be other than just viewing. E.g. if they are in content creation mode, then some visual cue that says so would be useful. If they’re in a mode where they might be reconfiguring the operation of Drupal such that it might disrupt the site if done badly, a MORE COMPELLING visual cue might be useful.

    But – given that there is not always a clear line between what’s Admin and what isn’t – I’m not convinced that the Admin functions should be _laid out differently_.

    As a side-note, the Joomla project’s Admin is completely different than the Front End. As much as Drupal users get confused about Admin vs. usage, (before I started using Drupal) I found just as much complaint about having a _different_ UI for the Back End in Joomla. We had complaints about front/back end separation – it’s just that the complaint was different: “What? I have to learn a _second_ user interface? Why can’t I just do it from the menus I’m familiar with.”

    So there’s some truth in in your #3; but it needs refinement.

  7. Disagree with #3
    The precise reason why I and many of us chose Drupal was the easily intgrated admin area and not having to “switch”

    1. It does not matter what “users” from other cms-es are used to. We are concerned with really new users. Aren’t we?
    2.News users, who are gen-x and use web2, and not clunky old cms-es are used to do admin jobs in star sites like facebook and similar sites to SAME admin interface as the site.
    3. Swiching back and forth between admin site and preview site INVOLVES EXTRA STEP! We are trying to minimize step, make things simpler.This also grossly breaks menu pattern, navigation etc.
    4. Ask you to review your results and test groups, I have tested with 359 admin users from 2006 Aug – 2008 Sept .98.9% wants admin interface to be nicely integrated as is now, without having to do clunky old swtiches.

  8. We have been participating for a long time in usabilty. Not just us but also many non-Drupal users. From many different parts of the web. There is an ocean of information but it was dried up, reasons unknown. For best results it will be good to revive this forum and NOT RE-INVENT WHEEL! Its here – http://drupal.org/forum/6

    x-posted for easy notice.

  9. @Leisa Reichelt Thanks for the follow-up but you’re getting a lot of this feedback (prompting your “woah there”) because of your wording. I’d suggest rewording your sentence/statements in the future to more accurately state that your looking for a way to notify the user that they are (a) logged in and (b) have certain privileges to change things.

  10. This is a good list, but as already mentioned by Mikkel and Jacob, I feel you’re wide of the mark with number 3.

    Most CMS systems encourage you to think about a site like a newspaper, a publication that is edited in one place and then distributed on the web. However, Drupal starts from different assumptions; it models a website as a collaborative information space in which users can contribute in many different ways.

    When users accustomed to the newspaper model start using Drupal, it jars. It’s foreign, and confusing, because it doesn’t fit into their existing preconceptions.

    After a few hours though, I’ve observed that they get the hang of it and really start to like it.

    Having a separate admin system inherently limits how you structure your community. If you think about it, as you get more and more engaged users, the line between ‘official’ and ‘user generated’ content starts to blur, and you could end up with a lot of duplicated interface to maintain.

    It’s also important to remember that Drupal core is really just a basic core, and that there are many contributed modules (eg the admin menu) that help to make managing content a much better experience.

  11. Principle #3 is were I think your lack of experience with Drupal as a platform negates some of the the genuine value you bring from a usability standpoint. It has been my continuing concern all along that this sticking point might be detrimental to your UX feedback in the long run.

    Drupals popularity and strength over alternatives can be directly attributed to its fluidity on what constitutes an administrative task. This is because drupal is used to create all types of sites. An “administrative task” for a blog site isn’t the same as an administrative task of an issue queue site or a social network site.

    More importantly our clients diversity of roles and workflow requirements would make any “defined difference” disjunctive and abrasive to the users who inevitably straddle the lines you create.

    Because these definitions change the proper INTEGRATION of the tasks is what makes drupal powerful not its ability to segregate them.

    To restate this very important concept:

    The dichotomy you create between “admin” and “website” is a false one and one that drupal wishes to do away with. You have only privileges, like facebook where there are things you can do (tag photos or create post/link) and things you cant (delete others content or accounts).

    I would be happy to speak with and work with anyone on the usability team at their convenience to try to explain the usefulness and importance of this point and provide a live sounding board for your feedback or questions.

  12. Additionally if you can please give examples of these principles in action our developer brains can actually get their teeth into them and we can give you more accurate feedback on their benefit and effect on the whole drupal ecosystem.

    These principles are surely born of shortcomings in the current system you observed so highlighting the most egregious offender and showing us how your principle sets it on the straight and narrow, adds value for us and puts your principle in better light. Otherwise we are debating the bets color for a hypothetical bikeshed. So what do each of these principles mean in practice? How does #4 manifest itself in node creation, etc.

  13. I totally agree with Simpson’s statement!

    I also have those experiences since our company started using Drupal to build sites for others (back in Octobre 2006)?

  14. I have a PhD in Human Factors and would love to contribute to this redesign.

    Maybe you already did the big picture thinking and are past the listening phase; but, I would like to put out my vision.

    You are working on the details of the interaction within Drupal. I am interested in the big picture that keeps people from even using it.

    These are endpoint goals that can probably never be achieved.

    1. Installation. Similar to your #6. It should be like OS X’s installation of applications. Drag them to the Applications folder and they work.

    – Drag Drupal to your website and it works.

    2. Updating. There should be something like Apple’s Software Update feature. – Drupal announces there is an update available.

    – You say update and everything in Drupal, including modules, are updated.

    3. Theming. The ideal theming would be to click a button that says, “Make It Look Good” and it does. I know this will never happen but theming is programming in Drupal and Contributed Themes all work differently and, of course, not exactly the way you need them to; so, you have to go back to do your own.

    -Drupal Theming should be graphic design not programming.

    4. Modules. “Does anyone know how to make Drupal do ‘X’?” This is a really common question in Twitter. The answer is that there usually is at LEAST one module that does “X”. How do people find modules? How do you know what the best one is? How do you know how it plays with other modules. I have over 1000 modules in my sites/all directory because I like testing them out. But of course my sites are constantly broken. http://drupalmodules.com/ is a start, but it would be better if Drupal had a way during site building to answer the question, -“How do I make “X” happen?”

    -Drupal answers the question, “How do I make “X” happen?”

    5. Modules (part 2). When you install modules blocks and fields mysteriously appear. (Or don’t appear because you have to go turn them on in blocks.) It would be great if every tab, input field, block, etc. had a tag on it which let you know which module put that there. It would help with site design.

    -Drupal lets admins know where everything on the page is coming from.

  15. “Drag Drupal to your website and it works”

    This is exactly what Cpanel provides.
    Click “Install Drupal” and everything, including the database, is ready.
    Takes less than 3 second!

  16. I’m really not sure what all the controversy is about the separation between admin and website sections is about. The backend/frontend dichotomy is a familiar principle in everything from stores to live theater. Sure, we shouldn’t do it just because everyone else does it. At the same time, we should realize that everyone else does it because it’s a familiar pradigm that people are used to working in.

    But this is where Drupal’s great theming system comes in. As Leisa correctly points out, it’s a question of theming, not of architecture. If admin users are getting confused, why not enable a different admin theme out-of-the-box? It follows along with principle number 4 (sensible defaults). I’d suggest the Rootcandy theme as a great candidate.

    In addition, it would be smart if Drupal provided an interstitial warning to the user if they do switch the admin theme to the same theme as website, along the lines of:

    “You’re about to change the administration theme to the same theme as the website. Pages where administration functions are performed will have the same style as public-facing website pages. Please note that some users with permission to access administrative areas of the website may be confused. Are you sure you want to do this?”

    The wording would likely need to be changed. But that way if admins get disoriented, at least they were warned and can always switch it back.

  17. I think this dichotomy is not that common or even does not exist in our day to day software applications. When I type, view and save in Microsoft Word or even Notepad there is no front end and back end. Same with Paint and Photoshop!

  18. @amc What is an administrative function? is it creating content? Deleting content? Voting on content? Commenting on content?

    Drupal has intentionally never delineated between administrative functionality and normal use items precisely because different use cases dictate who can do what. we have privileges and I personally seek to remove and inline all administrative control to sensible locations within the natural flow of working with your objects on a daily basis.

    Practically speaking this means things like “promoting delete to a menu local task” on nodes so it isnt hidden as an admin function but as a decorator of the object itself. It also means eliminating discrete settings pages except where necessary and no obvious object would serve as a decorator (I’m looking at you block editing!).

    The lack of the dichotomy really expands our capabilities to respond well to different use cases (issue tracker, social network, etc) and i personally dont think it hurts us much in the “drupal as a blog or pulishing platfrom” either. The trick imo is to do this intuitively without cluttering the interface and in a fashion that can be extended across all of contrib as well.

  19. 1. Yep, this is the big, overarching one. Most of the current UI reflects Drupal’s technical model, not the user’s mental model. Drupal has been succesfull because of the strength of it’s technical model and has been able to grow despite it’s UI until now.

    2. yes, yes & yes. Lots to win here! 🙂

    3. I don’t see a problem in this. It doesn’t state where the exact line between front and back, create and admin etc. should be drawn, just that it’s important to always be clear which side of the system you are working on. You switch on the tv on the front side. Cabling and power cords are usually on the back side. Most of the times you just use the remote control. Whatever *you* decide you want to be on the front or back is up to you and fully customizable on both the tv and the remote.

    4. I’m sure it’s possible to find sensible defaults for this if we can agree on the focus for the default install profile (http://groups.drupal.org/node/21013 ? or http://groups.drupal.org/node/21014 or something else?)

    5. Very curious how the tone of voice excercise pans out!

    6. Ship with dummy content? It will be interesting to think more about that phase where installation ends and actual use of Drupal begins. I’m definately in favor of letting people create their first “Hello world” post as quickly and smoothly as possible.

  20. I kind of agree with what michaelfavia is saying. The most obvious and common tasks can be pushed right inline with the front end content but what about the more involved procedures? Front loading all the functionality is too easy to turn into a mess but if we could execute on that in a way that made sense, it’d be amazing. We would have to keep in mind how contrib would tap into the system and the burden it would place on theme devs since they would have to take into account more variability in what gets push out to the client.

    What delineates an administrative or permissible task from only being able to view it is very important. Leisa wasn’t entirely clear on point 3 but she made it clear enough in her comment. This is what’s confusing about Drupal now. There’s no clear context on where you are or what you are doing. The page layout and design doesn’t have to deviate too much from the main site but what you can do and the state you are in must be made very clear. And to be honest, the usability study that steered a lot of people to focus on an administration theme did not work for me. I think that was only one part of the problem.

    I’d also like to add a 7th point. Or rather, an overall goal… To be engaging and fun. I’d hate to bring up Apple since it’s so commonly done. When you have a task to do, you just do it. There is little administrative debris compared to Windows. We wouldn’t want to go too far in completely hiding some options (ever hack on a .plist file?) but it ends up being fun to work with since the task at hand can be focused on instead of the system getting in your face while acting like it’s your problem.

  21. Lots of good stuff here. All great guidelines that will help.

    Re:3, This is always a hot topic. I think Jacob Redding said it best “notify the user that they are (a) logged in and (b) have certain privileges to change things.” I believe this is all you were trying to say.

  22. “Make Drupal fit the user, not the user fit drupal”

    This summarises for me, many open source projects problems.

    Yes its great that a community of coders can make Drupal and Linux, but at the end of the day, as a specialist group, their paradigms are quite different from every day users.

    I think you are right that this is the key design concept for Drupal.

    If you can then move on to GNU/Linux next I’d be VERY happy.


Comments are closed.