Who is D7UX for?

Who is D7UX for?

As we start to get some outputs that are getting higher and higher in fidelity (that is, more like what they’ll be when they’re done), it becomes easier and easier for more people to take a look and give their feedback. This is great, but it’s also a challenge. Why so? Well, because, D7UX isn’t for everyone – and if it’s not for you, then in order to give feedback we can work with you need to be able to put yourselves in the shoes of someone it *is* meant for, or better still – find one of these people and try it out on them.

A well designed interface doesn’t work for everyone all the time, that’s just an impossible dream. It should work for it’s defined target audience most of the time though, and that’s what we’re aiming for.

So, who is D7UX designed for?

There are two main audiences that we’ve had in mind as we’ve designed this interface for D7.

  1. Our ‘Clients’, the Content Creators – the first group we’ve broadly named ‘our clients’ because for many of the community who make sites with Drupal, these sites are then turned over to another person or group of people who use Drupal to add and maintain content on the website.Often these people share the following characteristics:
    – They’re not developers. They don’t know much about code and how it works,
    – They’re not in the Drupal community, they don’t love Drupal as much as we do, they don’t speak Drupal-ese,
    – Updating the website is probably just one of many jobs they have to do,
    – They’ve probably used other Web Content Management Tools than Drupal in the past.

    These people tend to have a small number of tasks they need to do on the website, and those tasks tend to be repetitive.
    The best thing we can do for these people is to make those tasks as simple, question free, and error free as possible.

  2. Non-technical Site Builders – these guys are a whole other kettle of fish. They have a more advanced understanding of what technology can do and how code works, but they’re not developers. They are, however, considered technology or web experts in their field, which may be something like academia, or ‘social software’ or they may just be the person at their tennis club or church who ‘understands the web’. People expect them to be able to build fairly sophisticated websites and they’d rather like to be able to do it themselves too, except without the technical skills, it can be hard. You’ll probably find a bunch of these people currently using Ning.Often these people share the following characteristics:
    – They’re not developers but they do understand quite a bit about how code works and may be able to write and understand a little code themselves
    – They find themselves needing to create websites (often for others) that have fairly sophisticated requirements, including forms, community tools, online stores, and content publishing using a range of page templates.
    – They have experience with a range of online content publishing tools.
    – They have probably heard of Drupal but had little experience with it before and certainly don’t speak Drupal-ese

If you know anyone who fits one of these two descriptions then these people will be idea test candidates for the D7UX interfaces as they emerge. If you don’t then here are a couple of very sketchy ‘personas’ you should consider when evaluating the usability of D7UX.

Verity (our client, the content creator)

Verity is a part time administration assistant for a cancer support charity. She is working part time while she completes her Social Care Diploma. Before she left work to study, Verity was a Personal Assistant in the Finance Sector. Verity is in her late twenties. She is quite proficient with the MS Office Suite (Word, Excel etc.), and she uses Facebook and email but she doesn’t consider herself very good with technology.

One of many tasks Verity has to complete each week is to update the ‘news’ section of the website and any other small content updates that are given to her to make by more senior staff. She doesn’t mind this job but she is often interrupted by the phone and other staff while she is updating the website, which can make it tricky for her to remember where she is up to in the process. If she has any trouble with the website updating there is an IT consultant Verity can call, but she likes to avoid doing this unless something is very broken as the consultant is both very busy and expensive!

What Verity Wants: to be able to complete her website updates quickly, without getting confused, and feeling confident that she’s knows where she is and what she’s doing at all times.

Jeremy (non-technical site builder)

Jeremy is a social software consultant (no, he doesn’t like that job title either). He works with medium to large organisations to help them understand how social tools could help their businesses be more successful and he recommends tools that they should use and how they should be implemented.

Jeremy is often frustrated because it is difficult to customise existing tools to suit his clients. Also, he often has to use tools from many different places to put together the solution they require. He would love to have the ability to ‘build’ a site that would meet his client’s requirements, however his technical skills are not great – for example, he can edit some PHP code to get it to do what he wants, sometimes, but he can’t write much from scratch. He understands what CSS is and what it can do, but he’s never written much himself.

Jeremy has friends who are developers and professional designers and he can call on them for some assistance. He heard of Drupal a few years ago at a social networking event and tried downloading and installing it but didn’t get very far and his general reaction to Drupal now is ‘it’s scary’.

What Jeremy Wants: the ability to build sites with rich functionality and flexibility without have to write code.

Note: these are not formal personas, they are just quick ‘sketches’ drawn from the research we’ve done to date (since August 08) that we hope will assist you to evaluate D7UX interface design.

What about the developers?

Good question. We do care very much about the Developer Experience (DX) but we also know that many developers are perfectly happy with Drupal the way that is is (as long as they have the Admin menu installed) and that they, of all people, know that essentially all Mark & I are doing is ‘theming’ the admin and that they can override this with ease. We’re not doing anything to The Way Drupal Works that will inhibit their ability to do all the amazing things they do now, and more in the future. Having said that, we hope that they are pleasantly surprised by the interface and might even consider keeping it. Or, perhaps, at least part of it. And in particular, we hope this buys them more time to do what they’re great at – development work – rather than spending that time training and supporting people who know (and need to know) Drupal less well.

26 thoughts on “Who is D7UX for?”

  1. That last line is really important. As a developer I want an interface that is easy to train clients to use because it’s consistent, has minimum number of steps for common tasks, and is visually compelling.

      1. sorry, I was under the impression that a reply about UX to a post about UX on a site about nothing but UX would be relevant, my bad

  2. did you really use a webcam to take a picture of a post-it you could of re-created in PS/IL in like 10 secs?

    I can’t even read the text on the post-it… bad UX if you ask me πŸ™

  3. Many developers, especially those who regularly use/build other systems, are very UNhappy about the usability of Drupal. Not only is it a pain to make it usable for clients, but quite frankly a lot of the interfaces we use deal with complexity poorly or are downright confusing (quick: where do you go to flush the permissions cache? That’s right! Content Management->Post Settings! Of course!).

    So some of the work for Jeremy should benefit us, but some attention to common tasks developers need to accomplish through the UI would be appreciated.

      1. I sure add, edit and re-arrange a lot of menu items. I bet Jeremy and Verity do too.

        Configuring Blocks is a bit of a pain too.

        Can I get a “check all” for permissions by section and for the whole thing? Sometimes it would be easier to check everything and then uncheck. The current admin makes me not want to create any new roles, it just hurts. If it at least had a copy role, that I could then modify…

        Too be fair I’m barely able to get Drupal up and running on my own (but I can) so I’m not very good with Drupal and I’m certainly not a php programmer.

  4. this is exciting. i’m a js/cf developer and i’ve deployed a bunch of drupal sites. the simple fact is that theming involves learning a hell of a lot of drupalese, even if you are proficient with all the related technologies.

    1. unfortunately, i don’t know how far we’re going to get with making theming less tricky… it’s an issue that goes way beyond the admin UI, but it’s an issue close to our hearts. We hear what you’re saying!

  5. Edit in place is hardly a retheming of the admin interface. It has potentially deep reaching impacts on DX along with a number of your other proposed changes.

    I think mos of us see value in a lot of your proposed UX improvements some of us just see the limitations or additional overhead and abstraction it imposes on our infrastructure as well. Our reaction is just an attempt to keep things as simple as possible to ensure is that we dont make our jobs harder than necessary. Incremental improvement over radical redesign.

    We build Drupal, the sites that run it run, and the contributed modules that make it more valuable. If we get lost/hurt in the shuffle the engine that drives this wonderful beast runs out of gas. All the Veritys and Jeremys in the world can’t will progress, it has to be forged and managed in our complex development ecosystem.

    I value your input and ideas and I personally hope to help integrate the good ones into our project. I just happen to think there are alot of other candidates that have a much more proven track record that deserve consideration as well.

    1. fair call re: edit in place, and that’s something that’s fairly low on our priority list for development and certainly not critical to the overall UX strategy.

      that aside, I’d like some more detail on these concerns ‘the additional overhead and abstraction it imposes on our infrastructure’ – we are really trying hard to make the UX as far as possible a ‘magic layer’ over the top of the Drupal infrastructure, not changing the way that Drupal works but changing the way that it is presented to the end user. If we’re breaking this at any point, I’d really like to know about it.

      It has to be acknowledged though that the way that Drupal works now for the end user is as far from ‘as simple as possible’ as you can get. Something has to be done about that, and it’s going to take more than fixing an screen here and a screen there to achieve that.

      As for the other candidates – we’re listening! If you have any particularly in mind please share them with us, and also note that particularly on the more detailed/specific interfaces we’re going to be working closely with the Drupal UX team who have a much more intimate knowledge of the ins and out of Drupal’s infrastructure than we do, which I think will help everyone enormously.

      1. The following is entirely my own pet theory, but maybe it helps explain the situation:

        The personas you identified above are not necessarily three different people. Many, many people who are currently “hardcore Drupal developers” started off exactly like Jeremy, and quite a few even started off like Verity. A bunch of us don’t have anything resembling a computer science degree, and none of us have a clue what we’re doing πŸ™‚ But the reason we are here is that there appears to be some kind of magical thing about using Drupal that transforms Veritys into Jeremys and Jeremys into developers — much more so than in other projects. Sure, Drupal is primarily a site building tool, but it’s also surreptitiously an educational tool that has the ability to turn “normal people” into developers and thereby keep the project going strong while also empowering those people to do things they never thought they could. I’m not sure anyone really knows exactly what the magical ingredient is, but it’s key to Drupal’s success.

        I think when a lot of developers hear things like “adding a layer over the top of the Drupal infrastructure” they are subconsciously worried about two things. First, that this will result in a dumbing down of Drupal, where people like Jeremy will be encouraged to settle for “good enough” and not delve deeper into how things really work. Second, that this will result in a large amount of complex code added to Drupal core, which even if is easy to override, still needs to be maintained, examined and considered any time other changes to Drupal are made. Drupal 7 is already much harder to learn how to program for than previous versions of Drupal were, so it’s a real concern that if the code gets too complex, people like Jeremy will have trouble making the critical leap into the world of Drupal development.

        Personally, I think these concerns have some legitimacy but also are a bit overblown. Mainly because if Jeremy’s initial introduction to Drupal is so frustrating that he runs away screaming, then obviously he’ll never go on to become a Drupal developer anyway πŸ™‚ And I think this D7UX effort is going quite well already — the main problem is just the time constraint it is under. But here are two (very vague) suggestions that might help address some of the above concerns:

        1. Make sure to think about usability not just as making things simpler, but also about more effectively educating the user. Try to look for ways where people can *start* using Drupal with a simple interface, but then progressively be guided towards more advanced functionality when they are ready for it — and where the advanced functionality (already present in Drupal) also becomes as simple to use as possible πŸ™‚

        2. Make sure that different components of the D7UX designs don’t depend on each other too heavily. That’s hard, but unfortunately it’s the way Drupal works (lots of pluggable functionality, most of which is not in Drupal core). If the header requires something else to work which also requires something else to work which also requires something else to work, then in the end the whole thing might not work.

        1. Simple start, moderate middle, complex end. Keeping it simple (stupid) isn’t just about the end product. We also need to keep it simple now, during the UX development cycle. So far, the complexity of the UX project has driven people off (including me) as has the constant bickering about changes and new directions.

          I’d love to see a UX project which worked like the theme system, switch the UX on Drupal at the touch of a button.

          Make a Starter UX, a Journey US, and an Expert UX.

          Leave the Expert UX exactly as it stands today and focus changes on the Starter and Journeyman levels. That would allow us to meet the needs of new users without being blocked at every turn by experienced Drupalers who don’t want to relearn the system.

          On a bit of a separate note, UX people always forget that most UXs are easy once people are used to them. It’s not like we’re born knowing that underlined text is a hyperlink ;-). And don’t make the train track mistake of thinking that we need to meet the expectations of new users when it comes to a UX, functionality and logical structure are more important because those characteristics will make people want to use the software and make it reasonably easy for anyone to learn, regardless of background.

        2. “Make a Starter UX, a Journey US, and an Expert UX.”

          I definitely agree with that idea. The thought of giving someone the ability to jump into an un-themed instance of the current admin site is scary.

          I’m a developer – just a not a php or Drupal developer. But I feel more like “Jeremy” – maybe even less so. I can get Drupal up and running – but I’m not taking the time to customize a theme. I’ll let my “clients” (church, neighborhood association, kid’s school, family, etc. – all things unpaid) pick the theme that is the best fit, and then maybe tweak it just a bit. But that almost never entails changing the admin side of the site – and that is what needs it the most if I’m ever going to turn it over to someone else.

          And I’ll certainly say this again elsewhere: You need to split out the personas into maybe “perspectives”. (I’m guessing at the appropriate word). Instead of trying to figure out what the “Starter UX” is and _who_ it is for, perhaps thinking of it as what _type_ of website is this, and build the UX around that more than just the persona.

          I realize that once you start to combine all the various types of sites, this because more unwieldy/less “Starter UX”, but we’ll call that the “Journey UX” – a little bit of everything, just not every bit.

  6. These audiences are so appropriate, it hurts.

    Michael Favia has a point, to be sure: If the demands are too high on the core developers, they’ll leave or fork or vote by removing their time. Fair enough.

    But without Verity and Jeremy, Drupal is a niche tool.

    As a person trying to actually put Drupal into websites maintained by Verities, I have to tell you, it’s a major chore. I just completed six hours of training on a site implementation, and that only got through the very basics, truth be told.

    I understand that in principle Drupal can be re-made to be simpler. But simplicity takes a lot of work, and there are no core tools at this point to clone your hard-won simplicity.
    Furthermore, we’re down here taking our best guess at it and most of us don’t have the bandwidth to even do discount usability testing on our efforts. We test it when it’s delivered to a client.

    If Verity and Jeremy can’t use it, it won’t prosper. If that’s fine with the core developers, then so be it. But one thing that’s remained unspoken but might ought to not is that there’s plenty of structural evidence that Dries & co. see a powerful need to speak to Verity and Jeremy. That’s how Acquia is going to make money. That’s how Lullabot makes money.

    If you don’t want to think of it in terms of money, think in terms of client service: We’re craftsmen making a product, and if the client isn’t satisfied with our work, we didn’t do our job right. Part of doing our job is how we choose our tools and materials. If it’s hard to get a satisfying product made, a lot of us will find other tools and materials to work with.

    Me, personally: I’m somewhere between Jeremy and a developer. To me it seems clear that for Drupal to be a cost-effective platform for the kind of sites that my agency builds, it’s got to be entirely buildable by Jeremies. Right now, we’re not really cost-effective on Drupal because I have to spend too much time being a developer, and not enough time being a Jeremy.

    1. I have to say, I think Joomla does it much better on the “Jeremy” end of things. (not sure if those are forbidden words here). It’s a struggle for me every time someone asks for a site. I know they’ll be better off in the long run with Drupal. If every I set them up with Joomla, just as soon as they get their feet under them (sometimes sooner), they start asking for things that Joomla just can’t deliver (at least not without me being a php developer and Joomla developer second).

      From an up and running out of the box perspective, Jeremy probably wants to select at install “This is a blog site” or “This is a photo site”. He’ll happily wait as the regular, but non-core packages (all of the correct/compatible version) are downloaded. When the site comes up won’t he be delighted that it looks something like a blog site that just needs a light touch, which will be easy because the “Starter UX” admin screens are configured more for a blog site.

  7. These two roles/personas are so right on target, it’s like I know these people. Great out-of-the-box roles…

    There is also an increasingly common “Communications Director” or “Project Manager” kind of role (as Drupal attracts bigger fish), but it seems you’ll be able to easily piece that role together out of what D7UX is doing for Verity and Jeremy.

    The hypothetical Communications Director is responsible for managing multiple “Content Editors”, “Non-technical Site Builders”, and 3rd party consultants — perhaps 5 to 30 users for a given site/campaign, and in that respect they’ll appreciate what’s being done for “Jeremy” in terms of user/role management…. They’ll also like what’s being done for Verity, as another of their jobs is moderating lots of content (including taxonomy and other meta-content), produced by the public, paid staff, and contractors alike.

    So — nice building blocks πŸ™‚

    1. W.r.t. those communications directors: One thing that I’ve seen to be true — I said this above but I’ll say it again — is that the person directing and approving the work (the manager/supervisor/lead/subject-matter expert) is often in general NOT going to be the person who has detailed knowledge of how a system works.

      Put another way: The boss is often the last person you want actually doing something on the system. (Many bosses — the better ones in my experience — are self-aware enough to know this; some aren’t.)

      So that means that the “Reviewer” persona doesn’t necessarily need as much power, or at least, doesn’t need it in the same way, as the person responsible for maintaining the site’s content on a day to day basis.

  8. Okay. I need a little help understanding something. Is there much difference – functionally speaking – between D6 and 7? is 7 a purely a UX overhaul? And all nodes are UI projects?
    Reason I ask is that like some others here, I’m basically Jeremy creating a community site for Verity. I have little experience with Drupal, but it has been awhile and I’m going to install an instance from scratch. Do I install 7 and expect all modules to function or do I go with 6 which might lead one to think it’s more stable because there are less issues.
    Apologies if this sounds dense or has been answered elsewhere. I’ve looked, but not found an answer. Thanks!


    1. Hi Chris,

      The short answer is that Drupal 7 is still being built! It’s under heavy development now, and probably won’t be officially released until late this year or early next year. But there are already tons of improvements over Drupal 6, both in terms of functionality and in terms of UX. This site here is where some mockups of possible UX improvements are being designed and discussed, but the overall work to implement changes happens on drupal.org and is ongoing. You can see some of the overall community initiatives here and get involved if you want to: http://drupal.org/community-initiatives/drupal-core (some of that page is aimed a bit at people with heavy Drupal experience, but other parts aren’t).

      So if you’re building a site right now, you should definitely use Drupal 6; Drupal 7 is not yet ready for production use. But no worries, because there’s an upgrade path, so once Drupal 7 is available and you’re ready to use it, you’ll be able to upgrade your site to take advantage of the new features and improvements.

      1. Hey David- Thanks for the clarification. Will explore and look forward to helping in anyway that we can. Are modules going to reworking for compatibility with D7?

        1. Great! Yes, most modules (especially the popular ones) generally do get updated, although there is often a lag. So if past experience is any guide, there won’t be a whole lot of contributed modules available right after D7 is released, but as time goes on, more and more will get updated.

  9. I used to have ten developers who worked for me developing Drupal sites beginning with D4 and D5. As a team we felt we attempted to jump to D6 too soon in early 2008 before many of the modules we needed to meet our client demands were ready for prime-time. So the transition to D7 (we did finally transition to D6 in early ’09) will be one that will be important to us as a Drupal shop – even though I no longer have ten developers and am doing more and more coding on my own.

    As someone who manages projects from simple brochure-type sites – with the bulk of the content being fairly static – to very complex sites – with a lot of content types driving complex functionality and high-end themeing – I can tell you that banking the entire farm on a framework that, at times, can be inherently frustrating is a bit tumultuous at best. Since becoming a strictly Drupal shop, I have often wanted to become more active in the Drupal community on a development level. My hope is that I will be able to stabilize our course within these tough economic times enough to allow us to do so at some point. But until then I want to do something that I don’t think is done NEARLY enough, which is to thank those of you who HAVE managed to get to that point. Without you we would be stuck with the Joomla’s of the world, and that is more frightening to me than any trepidation I may have when trying to leverage the strengths of an ever-evolving framework.

    We love Drupal!

Comments are closed.