There is a design game that I like to play when I’m working face to face with my client (and when there aren’t thousands of stakeholders!) which involves everyone on the project sitting down together and individually sketching up some wireframes that then get shared back into the group.
Aside from being good fun, it is also a really great way to uncover good ideas, common themes, and a whole raft of information and assumptions that haven’t yet surfaced in the project but that are important to us getting the design and information architecture right.
I don’t see why we should let our ‘virtual workspace’ stop us from playing this game, so, let’s do it. Let’s do some wireframing together!
Here’s what I want you to do:
pick a page on Drupal.org – it could be the homepage, it could be your profile page, it could be a project page, it could be a page that doesn’t exist that you think *should* exist – just pick one that is important to you.
have a go at sketching out what you think might go on that page. What are the content and functional elements, and which ones are the most important.
post the page somewhere – if you’re using Flickr, you can post it to our Flickr Group, or perhaps you want to post it on your blog and put a link to your post in the comments here, or you can email it to me if you like and I’ll post it – whatever you prefer. You might want to add some notes as to why you’ve approached the page the way that you have or, if you’re like me, to decipher your handwriting.
You can use whatever you like to wireframe – I tend to use pen and paper to start with or sticky notes. Then I’ll use Omnigraffle a little later. You might prefer to sketch in code. Whatever works for you. As you can see from the example I’ve posted above, early wireframes are usually pretty rough (mine disintegrated into a list at the bottom!) and not so pretty. This is fine. It’s not about how they look or even whether they’re right. It’s about getting ideas down on paper – to paraphrase the old saying – a wireframe is worth a thousand words.
Don’t spend too long on it – try to spend no more than a few minutes on a wireframe. If you’re not happy with it (and you probably won’t be at first!) just put it to one side and start fresh. You don’t want to labour over them too much at this stage.
Don’t think you have to be a designer or a UX person to participate in this exercise – this is all hands on deck. Even if you’re not an experienced Drupal user and you were flummoxed by your experience of Drupal.org – what did you *want* to find on the homepage?
I know there have been lots of discussions over the years about various parts of Drupal.org – let’s roll up our sleeves and get stuck in! Yay!
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 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 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.
There are many reasons why I am tremendously excited about being involved in the redesign project for Drupal.org, not the least of which is that – for a change – I’m actually allowed to talk to you all about the project as we go. Afterall, it’s an open source project – we don’t care so much for confidentiality and Intellectual Property, what we care about here is being open and being part of the community.
Exciting yes? but also somewhat terrifying! What an amazing (and enormous!) community to try to become a part of! As Mark said in our keynote at Drupalcon – it feels like being the new kid at school – will we make friends?! But one of the things I’m really thinking hard about is how to harness their amazingness in the best way for this project?
Back in the olden days I was a project manager, so I have a great appreciation for an approach that works to limit the amount of feedback that you take into a project – how much, how often etc. Trying to get ‘consolidated’ feedback has traditionally been the goal, so that we can move through the design process as efficiently and calmly as possible.
As a part of our plan we have already factored in ‘community feedback’ to the iterations of the prototype that we’ll be releasing from very early in the design lifecycle – the community *will* be involved in this project, albeit in a somewhat structured way.
But, against all of my project management instincts, I am itching to get as much community involvement in this project as I possibly can! To encourage the entire community to think about things like experience strategies, and information architecture and user centred design.
I am tempted to set up a Twitter group (@drupalredesign perhaps) where we can all tweet little brainbursts we have about the redesign. To set up a Flickr group where we can all post annotated screenshots of stuff we like, stuff that’s broken. To blog about half finished ideas I’m having about strategies and solutions we’re working on.
This is all ridiculously dangerous from a expectation management perspective – there is no way on earth that we could make any assurances about taking everything into consideration, answering every suggestion or issue raised, solving all of the problems…. (don’t let me start coining a project management buzzword that involves ambiance!)
And yet… it’s also ridiculously exciting.
Already, from blogging about the gaming / karma issue, I’m now talking to someone out in Drupal land who is already working on a module we might be able to use. I wonder whether we would have made that connection otherwise.
Eh. I almost feel as though it is inevitable. We have to open up completely, and just see what happens.
I’m almost certain some expectation management/ community disasters will ensue, but hopefully also some amazingness. I’m sure you’ll hear all about it as we go!
What say you? Am I having a moment of insanity? Or shall we open the floodgates and see what happens?
I was talking to someone recently about doing some work with them. They said ‘can you send me some examples of documentation you’ve done lately’ – they wanted this to check that I could do what I said I could. Fair enough. Except, aside from the fact that all the documentation I’ve done lately is commercially confidential, so I’d have to hack it around a little to be able to show it to someone else… it made me realise how long it’s been since I’ve actually done the kind of ‘finished’ documentation I used to spend a lot of my time doing.
I just don’t work that way anymore, it seems. Sure, I still do wireframes every now and then, but never a ‘complete set’ and often with no where near the detail I used to include. Why? I think there are three reasons. Firstly, I tend to work on more of a strategic level than a detail ‘exactly where does that button go’ level these days. Secondly, I tend to work on projects where there is no time for that level of detail. And finally – and most interesting I think – I tend to work closer to the production team these days – more often are graphic designers designing and/or developers developing the very same stuff I’m wireframing at the same time. Investing too much in the documentation is a waste of everyones time – much better to do just enough to get them going and then work collaboratively with the team to do the fine tuning.
Personally, I think I should have been working more like this since forever.