Audience Matrix: Our thoughts on the Drupal 7 audience
Leisa and I have spent a good deal of time looking at how we can define the audience for Drupal 7. A couple of weeks ago, we spent a day trying to come up with an effective model to use throughout the design process. Not just a model that we could use, but one that could be available to the whole Drupal community as we embark on the challenging task of looking at the user experience for Drupal 7.
The Flappy Paddle
Before I start to talk about this tool, it’s probably better if you just watch this video Leisa and I recorded a week or so ago.
This is the tool we’re using, but at this stage, it was pretty rough around the edges. So, we’ve spent a little more time defining the various tasks and definitions for each different user type, site type, and number of users. Combining this detail, in various different combinations, gives us a list of requirements for that type of user, using a particular type of site, with a certain amount of users.
Sweating the details
Yesterday, we spent some time fleshing out the various tasks and definitions for each ‘paddle’.
This is what we’ve come up with so far:
- Content Creator: a user who primarily creates, reviews, and edits content for a site. Key tasks: Add content, edit content, find existing content, view list of content creation/revision tasks.
- Site Editor: a user who has authority to approve, edit or reject content and who may be able to manage some editorial workflow and user permissions. Key tasks: Add content, edit content, find existing content, view list of content creation/revision tasks, review content, reject/feedback on content to original author, schedule content
- Site Admin: manage user permissions, manage site structure, adding new content types, create and review reports and manage some site settings (RSS Publishing, IP Address Blocking). Key tasks: Manage user permissions, Add / Edit / Delete Content Types, Manage Information Architecture (site sections, sub-sections, taxonomy (as in, vocabulary), Create a report, Review a report.
- Site Builder: creates site from scratch by choosing, writing, customising modules and/or themes, manages setup and maintenance. Is a developer (for the purposes of audience definition, themers are considered developers). Key Tasks: Develop site functionality, implement site design.
Type of site
- Brochureware Site: hierarchical structure of relatively static content, often includes forms (eg. contact/feedback), may be multi-author
- Blog: sequence of chronological posts that may be assigned to categories, may also include ‘fixed’ pages, often includes comments, trackbacks, RSS feed, most often single author
- News: a categorical/hierarchical grouping of content usually ordered chronologically but often ‘curated’ by an editorial team, may also include comments, trackbacks, RSS feed, often multi-author, often requires multiple templates
- Events: a combination of content supporting an event, including content about the event, a schedule/calendar of events, list of participants, online registration, may also require online submissions, social networking functionality, news, email update list
- Social Site: comprises member profiles and communication between those member in the form of discussion forums, wikis, events, blogs, require member signup, subscription, RSS,
No. of users
- 1: no permissions, no workflow, that user does everything (one stop shop) BUT most like to have simple requirements (how manage giving access to all functionality when the mostly won’t need it). Likely to generate small amounts of content.
- 2-5 : multiple authors, may require permissions, may require workflow (simple approval process), may require separation between content management tasks and site management tasks but usually not overly complicated requirements.
- 6-15: multiple authors and editors, likely to require permissions, likely to require workflow, likely to require separation between content management tasks and site management tasks may have some complex requirements, will have significant amount of content generated.
- 15+ : requires permission management (several permission profiles), probably requires workflow (content review/approval), likely to generate a lot of content to be managed and require content scheduling - it’s a complicated machine and it needs a whole section around managing the machine, let alone making the content to feed the machine. Involves a lot of content and likely complex taxonomy.
And also, as you saw in the video, we’ve looked at using this tool now as we begin sketching out some ideas and concepts for how the admin may work.
An evolving concept
The Audience Matrix is work in progress and it’s going to be an instrumental tool for us in the coming months as we start fleshing out some of the design concepts. As Leisa says on her blog:
Over the coming weeks we’re going to be inviting you to submit your ideas for revisions to the Drupal7 Admin interface and overall user experience. It will be very helpful for us all to use this document to help make sure that we’re designing for the 80% and not necessarily just for ourselves! And it is also a really great way to expose missing elements and possible flaws in our concepts. Using the document to test the example we show in the video above helped us to realise that we needed things like a close button on the dashboard (I know, d’uh!), a place to hold the user generated content from things like comment as well as contact forms, and got us thinking about a whole host of thorny permissions and workflow issues.
We need your help. We’ve produced a PDF for you to download so you can use it in some of the upcoming crowdsourcing activities we have planned. (like the one’s we did for the Drupal.org redesign project).
There will be more from me
It’s a fair cop. I’ve not been as active blogging about this stuff as I could have been. Both the Drupal.org redesign, and now the Drupal 7 UX work, are both breaking ground on a process thought to be difficult, if not impossible. So, as of today, I’m going to be talking about it all a hell of lot more because, well, what other projects can you talk about as you’re doing it? We’re in an incredibly fortunate position.
Modularised stuff - where to draw the line?
I’ve got a several large projects ahead of me at the moment and it’s at that stage where you are mentally planning out how to go about certain things with the end result in mind.
There’s a fair bit of talk about modularisation at the moment, not only for content, but for the HTML and CSS, and this is the way I’m currently going for the projects. This is partly based on past experience, but also I believe it’s the right thing to do, especially on large projects.
This is how I'm going about it...
Getting your head round the content
So, without going into too much detail, the projects involve multiple content types from uploaded images to forums, but it's mostly different types of text content - lists, tables, captions, not too many large blocks of copy (which is good I suppose).
The first thing is to audit the content and break it into common chunks, groups of data type which can then be addressed as if they were one entity.
Secondly, decide how granular you go with the content. Is it down to field? or just to the 'paragraph of text' level.
Thirdly, once you've got your chunks of content, or content objects, spec and wireframe them as detailed as you can.
I've begun by defining an html framework in which these objects will fit. This is basically a client-side solution in which I define different layout types, based on columns, and the content objects then sit within these columns.
I like the idea of seperating the framework from the content, simply because it also allows me to focus on objects individually knowing that the overall 'layout' configurations are taken care of.
This is how it splits down do far:
- Content objects (defined in content audit)
Number 3 is the one where things could get tricky. How far do you go with CSS modularisation? Do you have different stylesheets for colours, structural layout etc. Or do you just have one, which is flagged (as in Doug's interesting article).
The problem I've got is all these content objects, each with it's own bit of CSS, could make modularising CSS extremely difficult to maintain - you could end up with over 30 stylesheets being imported. Not very practical.
How would you go about something like this? Would you modularise to that level or would you just bung everything in one CSS and use flags to navigate?
Some thoughts about signs
For a few years now I’ve had a bit of an interest in signage. Recently I was the only person to get a bit excited about a road transport exhibition in the Design Museum in London. Why? Well, signs are really interesting when you start thinking about them. So, here’s some thoughts about signs and how we, as designers, can look at them differently and incorporate some the ideas behind signage into what we do.
Signage does a number of things - it helps us get to where we want to go, it informs us, warns us and the list goes on. Let's deal with the first one... (or if you're not bothered, skip straight to the confab)
From A to B
Getting to where we want to be. It's a big deal, and signage helps us do that. The professional service dedicated to just this is called Wayfinding, and it does just that, helps us find our way. Wayfinding signage is found in almost every city, building and civilised environment on the globe, from official road signs to hand painted 'toilet' signs in local cafe's.
Having been involved in a couple of wayfinding projects I found the research and development fascinating. It usually involved developing a signage system, mocking it up in black and white prints and building wooden stands, then positioning them in a space and watching how people follow them. As they were temporary we could audit the people flow and make the required changes so that people could find what they want.
Designing a signage system is a little like trying to guess what people want to do in a space. For public buildings, like libraries and museums, they have to inform in addition to pointing people in the right direction. Museums are particularly interesting and, you've guessed where I'm heading with this, the similarities between museum signage and web site architecture are plenty.
Where's the f**king toilet
When somebody enteres a building, especially if they've had a long journey or they had too much orange juice in the morning, they will want to know one thing - 'where is the toilet', they will be single minded in that task as well. They will look for one of two things, a sign with the word, or if it's in another language an icon of a man or a woman. That's it. They shouldn't have to learn a new signage system, or try and work out a designer's 'creative' impression of what a toilet sign should be.
My point is this. Universal signage systems have been developed to overcome language so that manufacturers don't have to produce several products for different markets. This system works well until somebody does it differently and your daughter pees her pants because you couldn't find the toilets because they client wanted to be 'different'!
The same goes for web sites.
Provide clear signage
A user will come to a web site with a specific task in mind. Not going to the toilet, but more like they want to complain about something or they need to buy their daughter some new pants.
I may be preaching to the converted but putting the user first, understanding their goals and designing to them is the best way to deliver on the sites goals.
I know I'm opening up a big can of worms here with possible discussion about iconography, semiotics, usability, Information architecture, UCD etc. But understanding how signage works can go a long way to understanding how people navigate on a web site.
I've been doing a little reading on the subject and it's a bit like opening Pandora's Box. There is a lot out there, specifically on semiotics, but dipping into linguistics and psychology. It's quite difficult to filter some of the information and make it useful for you in a practical sense and you can't read everything right?
So, here's what I've found out so far...
Let's start with Semiotics
Semiotics is the study of signs and symbols and their use or interpretation. There are three main areas:
- The signs themselves
- The way they are organised into systems
- The context in which they appear
Extracting meaning from the signs is then possible once we understand the structure of the signs. They can be categorised like this:
How is this useful in designing for the web? Well, extremely and not just web design either but designing for any medium.
A person has to establish meaning from a sign or symbol. They then use this meaning to do many things, one of which could be to accomplish a task. The closer the design of the sign is to the task, the quicker meaning is understood and the task is completed.
There is of course the Usability / Aesthetic effect to take into account too. With this in mind applying it to web site design is actually quite straight forward.
A few things to consider
- When designing icons for web sites or applications draw on real world signage standards if you can. If you can't, try drawing on metaphor. Arbitrary shapes for icons will not work.
- When thinking about labels for your navigation, think clearly. Simple words for content will go a long way in shortening the gap between sign and task completion.
- Use colour carefully. Point users in the right direction with high contrast signs, or buttons. Just as you may speed down the road at 70 mile an hour and read a sign in less than 2 seconds, a user speeds through a website and may not give you more than two seconds. Be conspicious with your signs.
- Be consistent with your signage. Be it words or icons, be consistent in design and tone of voice. Let your users know what to expect.
There's just a few things I've picked up over the past few years. Once I get some more stuff worked out, I'll let you know. In the meantime I thought it may be fun to have a bit of a signage confab.
How about a signage confab?
Every designer likes icons or signs right? What's your favourite? This could be a photograph of one, one you've designed, sky's the limit. Usual confab stuff applies:
- Host the image on your server and link it in here.
- Simple HTML is fine.
- Keep it below 400px wide please or you'll bust me layout.
Oh, and here's mine...
Centred or Informed?
This has been rattling around my head for a good 9 months now and I think it's high time I went into labour so to speak.
About 18 months I got into the whole User Centred Design approach. I championed the use and creation of Personas on particular projects, got into user flows and scenarios, conducted user interviews and performed other research. This was all before any design was done. This really got me thinking and Jeff Veen's latest post sparked me into action.
Is UCD too dogmatic?
User Centred Design is just that, a design process with the user at the centre. It's a widely used process, and works very well in producing a product that the user can use.
The thing is, and what Jeff hints at in his post, is that things aren't always that cut and dry.
UCD is quite a rigid methodology, some would say dogmatic. It requires resources - money and people, but most importantly it normally requires a culture shift either within an organisation or on the part of a client. Here lies the problem.
Culture shifts are time consuming, expensive and don't always work. Key stake holders have to buy into the shift very early on and drive that change from the top. Even less 'top down' organisations have to have a key figure motivating that change across the divisions that need it. But UCD process is fundamentally a company wide shift in approach and culture. Let me give you an example.
A print design company, established over 15 years ago, offers a full service to it's clients from Branding and Signage to Websites. It's website offering has grown from brochure ware sites, to complex applications. It's team has therefore grown to include more web specialists rather than print designers. The creative director is the linch-pin of this company - what he says goes - and he's steered the company's creative direction for 15 years.
So, you've got this company whose creative director is used to working in a particular way which has served the company and industry well. I like to call it the "Designer Knows Best" model (hmmm, DKB methodology, got a ring to it don't you think?). All of a sudden a shift of culture is required by the company to meet market demand. UCD rears it's head. And all of a sudden, it's not about methodologies, it's not about users, it's about designers and their egos - end of story.
Maybe this example is a little cut and dry, but the fact of the matter is designers are taught to be problem solvers from a very early age (in career terms). Especially in print/branding circles it is the designers who deliver solutions (true, research generally informes these solutions) but rarely does the dogma of a UCD process enter into it.
User Informed Design methodology
What i'm talking about here is user research informing the design process. In UCD, this is formalised. You conduct tests, you design, you test again - iterate, iterate. Don't get me wrong it's a good model, but in a competitive market, where budgets are tight, there is simply not the resources, or impetus to change culture for a UCD process to be followed.
What i'd like to talk about is instead of User Centred Design methodology, many of us have already adopted a User Informed Design methodology.
The key differences between the two are:
- Past experience. Use past experience rather than repeat user research
- Get down and dirty. Adopt a similar working model to SCRUM. Get in there and start prototyping and designing straight way. Test informally as you go along.
- Graphic designers do graphic design. Use research to guide functionality and UI - not graphic design. (I'm sure many graphic designers feel disenfranchised by Information Architects and Usability Designs solving a lot of the problems and leaving it up to the designs to "do the pretty stuff")
- Boost ego. If your Creative Director is a bit a dictator, work with him to get at least some testing done but try not to prove him wrong - he won't like that. Try and prove him right, that way next time you propose more testing he'll probably say yes.
- Forget science. Scientifically gathered samples and the subsequent agency fees for recruiting are expensive. Unless you want to adopt a strict UCD approach and have the budget and will to do it, forget the scientifically gathered sample.
So some of this may not come as a surprise. To conclude, it's really all about being more flexible, relying on internal resources and your own experience with working with users before. It's about getting down and dirty with prototypes early and let the user research inform the design rather than dictate it.
The do’s and dont’s of Guide Book design
I thought it would be good to conduct a bit of research for an upcoming article i’m writing. Guidebooks are a kind of book I just can’t do without when going to a different country or, especially, on a city break.
On a city break, if you’re doing the whole cultural thing, you generally need overviews on what’s available, but then more information if you want it. You also need maps, and good ones.
For someone who had relied on Guide Books pretty heavily travelling throughout South East Asia, Europe and Australasia i’ve become very attuned to the design of guide books and specifically how a badly designed book can have a seriously detrimental effect on your travel experience. Like I said, I was thinking about this the other day whilst researching this article i’m writing and was thinking about a couple of things - 1. The design, 2. The access structure and 3. The information architure.
Sound familiar? A lot of the user/reader requirements mirror website requirements. A guide book, like most reference material, is constructed in a non linear fashion, categorised by location and meets the users task.
An author who understood this is Richard Saul Wurman, the father of Information Architecture, and his Access guidebook series.
I’ve seen a few of these books, but have yet to own or use one in the way it was intended (note to self, buy Access guides). I know the design and access structure of these books is by and large incredibly well considered, from maps and clever ways of orienting yourself, to well structured typography.
If like me you’ve had the unfortunate experience of going to a city with a bad guide book, you’ll relate to what i’m about to say.
A few years ago I took my girlfriend (now wife) to Barcelona for a surprise birthday trip. I borrowed a Time Out guide to Barcelona to make sure we made the best time of the couple of days we had there. As my father is an Architect I should have known all about Gaudi and his beautiful buildings. However, if you’ve grown up with a father as an architect you learn not to listen at an early age when he rambles on about crumbling buildings all over the world. Therefore I didn’t know anything about Gaudi. The guide book should have informed though. It didn’t, and we missed it.
I think the Time Out guides are great if you plan to spend more than a few days in a place, or you live there, but for a trip of a day or so I really don’t think they cut it.
So, back to the reason for this now rambling post.
What do you look for in a guide book? Does design inform your decision? Are loyal to a particular brand of book, eg Lonely Planet?
It’d be interesting to see some of your thoughts.
Where am I?
Had an interesting discussion today at work, mostly based on branding, but it made me think about some interesting things about user orientation. How many times have you asked yourself “Does this navigation work?”, or how many times has a project manager/client/boss asked “how does the user know where they are?”. My guess is quite a few.
A lot of these question focus totally on UI and design and not on what the user wants. Really when these people are asking these questions they really mean “i don’t understand this design” or “I don’t know where I am”. They are thinking of the user, but they’re thinking of them as being like them.
Here’s where I go out on a limb. I’m suggesting users don’t actually care where they are, they care what they are doing. This might seem obvious to some, and to me, but then I really started thinking about it.
If a person is reading about, say family history, on the ITV website. They then follow a link to another website about family history, do they know they are in another website? Probably. Do they care about brand affinity when they are in a different website? Are they aware of a different brand? probably not. Because they are reading about history.
Location isn’t an issue. The task is.
It’s similar in a car park. When you drive into a car park, you are focussed on finding a space nearest to your destination, this is your goal. Do you care about the design of the car park? No. You only care about it when it goes wrong and you’re directed up the wrong way or you can’t find the exit. It’s exactly the same with websites.
Brand and navigation should be designed to be invisible. What I mean by that is they shouldn’t get in the way of the users tasks, they should support them and help them when they feel they need it.
I know i’m rambling but I wanted to get this down on paper so to speak so I don’t forget it. Feel free to argue…
Icons, Wayfinding and Semiotics
Users don’t read. I’m not just talking about web users either. Ever spent more than 1 second reading a road sign? Ever spent more than 1 second reading a direction sign in a public building? Ever spent more than 1 second trying to use a websites navigation? That’s my point.
Designers for the web need to look more at systems design, semiotics and wayfinding for cues for their interfaces.
Take iconography for example. Iconography, especially in computing, has arrisin with the advent of more complex GUI’s, BUT it has risen primarily because of a series of common tasks which need to be illustrated in some ‘real world’ way.
This Image shows a number of icons displayed which show a number of common tasks. As you can see the design of these icons vary, but only subtly. There are some in each set which ‘feel’ right however, these are the successful icons which tap into the unconsious cues associated with semiotics. I question icon design and it’s validity within design. My experience of ‘icon’ design (and i’m not talking branding or logotypes here, just icons) is thay are a) Are not thought about in enough detail b) They are almost always decorational, therefore their function is often secondary to how they look. c) Most icons are so badly designed they need words with them in order to decifer their meaning. Not good.
Here’s a good essay on iconography and semiotics. Have a read, it makes a lot of sense.
Talking of system icon design, this is a great resource for comparing operating systems and their iconography.
Probably more on this later, when i’ve thought a bit more about it.
User Experience Accountability
As designers we’re all too aware that we are under scrutiny on how a project runs. These metrics generally define a projects success but Scott points out that they are not metrics by which we can judge User Experience and therefore an accurate ROI indication.