 What I am going to talk about is how you can create a process that does, that employs user-centered design and other techniques to create really great Drupal sites. In doing so, I did grapple a little bit with what user-centered design actually is, what it is in our current context. And I had a couple of different names for this talk. So it's been various stages in my work called user experience techniques for Drupal sites. And after Drees this morning, I also considered calling it building better web experiences for Drupal sites. But anyway, I think it covers any of those and all of those. So we're going to talk about some fairly nebulous concepts today. And if you think that your definition is different to mine, that's totally cool. So anyway, what is user experience? Well, it's kind of an umbrella term for an individual's interactions with a website or an app or a tool, whatever you want. As a discipline, it's mostly concerned with making the process of using a service engaging and interesting and relevant. But in itself, it draws on a range of other disciplines and techniques. I don't think user experience is a discipline, really. It draws on marketing, usability, interaction design, visual design, all sorts of areas, human-centered design. And if you're engaged in any area of site planning or interface or visual design or any part of kind of strategizing and putting together the way a site works for your users, you're doing user experience in some way. If you've come to the previous session, you've probably had a good introduction to that, so I won't go into that too much. Did my explanation gel with yours, Claire? More or less? Yeah, good. So what am I going to talk about today? Well, we're going to look at why traditional user-centered design and UX techniques can actually fail when applied to a Drupal build, the areas in which those processes can go wrong. What might happen? We're going to look at how you can resolve that by combining user-centered design, content modeling techniques, and interaction design, and I'm going to step you through a process for doing that. And we're going to look at a worked example while we do that as well, just so you know kind of what I'm talking about. If you don't understand anything at any point, stick your hand up. I'm perfectly happy to take questions while we're talking. Hopefully, we won't go on for too long. We'll do questions at the end as well. Anyway, what we're going to look at is something called UX Spaces. We're going to be talking about a methodology for bringing disparate processes and elements together. And this is a method that I've worked on and developed over my seven years of building with Drupal and a few years before that, working with other systems as well. So it's evolved from various practices. It's not prescriptive. If you decide to implement this or take elements of this, you should take it away and make it work for you, not just go away and do it because I said you should do it. So I'm going to start with a general discussion about some of the approaches you can take to site design, some of the pitfalls. You can think about where you've had similar problems in your own builds, how you might have solved them, how the way I'm thinking about them might have helped you in those contexts or how it might not, and whether you had other similar solutions or different solutions, how you solved them as well. While we're going through, we're going to be looking at a project called Parkfile. Parkfile doesn't exist as a project I've invented purely to work through today with you. Parkfile is a website in which people can find parks and gardens that they're really into to do exercise or because they're tourists and then we're going to see Versailles or something. All right. We're going to be looking at how Parkfile is set up. This is a wireframe. Most of you should know what that is. And we're going to look at how we can relate user spaces to wireframes and to build process. All right. So quick diversion, a little bit about me and my background. I'm currently a Drupal consultant with Previous Next, Australia's premier Drupal firm. I first used Drupal 4.5 but I've recently been fiddling around with Drupal 3 perhaps because I'm some kind of masochist. Don't do it. I've been working exclusively with Drupal since 2007, for better or worse. And I also help run Drupal ACT. I wrote a theming engine for Drupal 5 and then threw it away when Drupal 6 came out. I'm the maintainer and co-author of DisplaySuite for Drupal 6, not Drupal 7. So if you've got any problems with the 7 version, don't talk to me. And I have about 25 other modules on Drupal.org. Apart from DisplaySuite, no one's using any of them. So go figure. I don't know what that means. I'm not selling them hard enough clearly. I'm quite interested in the linked data and semantic web, high availability Drupal. And I'm also looking at things like MongoDB and other layout tools and various other bits and pieces in my own Drupal research. All right. So let's stop talking about me and talk about the problem. What is the problem? Well, we learn how to build Drupal components. You've all done this. You've sat down and you've learned how to build bits of a Drupal site. You've learned how to arrange, organize and design websites, probably entirely separately from how you've gone about learning to do Drupal, probably before in most cases. But sometimes bringing these two together has problems. I've used the word design in here, arrange, organize and design websites. I'm using this in a fairly general sense. I don't mean design in a visual sense purely. When I say design, I mean it kind of in a craft sense. So design is the process of thinking about how to build something, how to make something. So just, if I say design, don't take it too literally. Anyway, I kind of think there are three approaches to website design. Some of these are fashionable, some of them aren't. Some of them work well, some of them don't. The first one and the one that I'm sure you've all seen is the business-centered design approach. This is where a website is basically based around the structure of a business or the business's business model sometimes. Not strictly the structure of the business, but its model, the way it thinks about itself and does business. This approach focuses on the structure and needs of the business. The design is really strongly driven by the model and the requirements of the business as opposed to the users. The high level site architecture tends to map fairly well to the business. User needs fairly subservient to that process and it does tend to produce fairly boring sites unfortunately most of the time. Sometimes they work, but they don't tend to be very interesting. Then of course there's user-centered design and that's why you've come, because I put user-centered design in the title. User-centered design focuses on the needs of users primarily. Design is driven by the requirements of those users. The informational content structure is subservient to those requirements. Business structure is irrelevant and this can produce really nice outcomes. It can produce great sites, but it can be hard to implement in Drupal. The final type which I'm going to talk about today is content-centered design. Now if you've gone to an aquia training course, you will have been taught how to do content-centered design, because that's the way Drupal tends to work. Design is driven by content structure. We hope that content structure is driven by user requirements, but it may well not be. Drupal excels at this architecture. It's based on this architecture. Nodes, they provide this architecture for you. It's really easy to build sites like this, but they have the same kind of issues as other sites. They don't always produce great sites. The Drupal site that just lists lots of content under taxonomy is a prime example. Not that that's necessarily bad, but it can be. Anyway, the question is how can we bring them together without favoring one approach over the other? Because I think all of these approaches are perfectly valid ways to build websites. It's just that you don't want to do one of them and forget the others. Basically, you want to know how do you get your content to match the requirements of your audience? So let's digress for a second, talk about the elements of user experience. Has anyone heard that phrase before, the elements of user experience? Well, one hand. Here's a harder question for you. Does anybody know who this is? Very good. It's written on the bottom. Jesse James Garrett. Jesse James Garrett came up with this. It's called the elements of user experience. This is about 10 years ago, around about the year 2000. This was his explanation for how user experience works in the process of building a website. He started up the top with user needs and then over time he's worked through requirements, interaction design and architecture, interface, navigation design and finally a visual design. Alright, fine. Whoops, sorry, wrong slides. Yeah. Could have been. Yep, yep. Frequently we get the shorter version. This emits the user needs step. And it executes visual design prior to or in tandem with the information and interface design. This is about the worst kind of site build you can do. But it happens a lot. But anyway, that's what he did. User needs, spec, interaction design, visual design. Visual design, et cetera. But this is a distraction. He also said, as much as we want to withdraw into a world of pure problem solving, we have to acknowledge that the most successful architectures are the ones you can actually convince someone to implement. In other words, if you can't build it in Drupal, it's no good. It's not useful. If you can't build it effectively in Drupal, you're not going to have a good site. It doesn't matter how good any of these other processes are. So let's discuss the pitfalls of user experience. Specifically when applied to Drupal. The first one, and if you've ever tried to implement somebody else's design in Drupal, you'll know this one, is that Drupal's markup doesn't match the design. Drupal provides its own default markup for everything. So if you have to use other markup things get complicated. Now, this is a qualified problem. Sometimes that's quite solvable with other tools. And it is a common problem with many CMSs. This is not a Drupal problem. But Drupal does provide a lot of default markup, a lot of custom markup. So that is something that you strike. Another issue you get, and this is harder to solve, is the provided design mixes Drupal components. A really good example might be a menu that contains a text resize linked to the user's home page and a skip to content. Now, you can't do that in Drupal at the moment without writing it yourself. But there's not necessarily an incorrect way of doing it. So Drupal doesn't support it very well. Another problem can be that the design itself is fairly inconsistent in its use. So Drupal's structure is more or less fairly uniform. Most of the components that you get in Drupal are structured in much the same way. And the further forward we go in time, the more structured, similarly structured they become. If you have IA or designs that don't take a fairly consistent approach, then you have to selectively override things, and that becomes more difficult and creates more issues. Another problem is that the design or UX can favour interactions not met by the contrib modules. This might be a situation where somebody wants a special kind of ratings widget, and you know you've got five-star handy, but it just doesn't quite do what is required of the design. So what do you do? Well, you've got to implement your own or convince them that it needs to change. And a similar problem is that you can end up with complex interactions that are based on third-party JavaScript libraries with poor Drupal support. So these are some of the pitfalls that you can encounter. Lots of these pitfalls are that ultimately your Drupal side isn't as good as it could be, or it has higher maintenance costs, or it's just generally harder to build. So this takes time for everybody, produces outcomes that are harder to test, or just don't quite meet the requirements. Say you implemented five-star instead of this other thing. Maybe they weren't happy with that. Anyway, we're going to talk about maybe a way in which we can get around that problem. And this particular solution is called user experience spaces. I didn't actually make this term up. I've heard this somewhere, and I can't remember where it is, and I can't find it on the internet. So this is somebody else's idea. It's not mine, but I don't know whose. Anyway, what are UX spaces? UX spaces are a way to represent the interaction between the user and the content in a way which has practical outcomes and can be the basis for an actual builder implementation. In a really theoretical sense, a UX space is a set of bounded interactions between an actor or a user, and the content model, we define a UX space by the intended audience, the type of content and the interactions that are required. And then we can make this match up with website sections, pages, widgets, applications, or task spaces. So we can actually define what a user wants to do or needs to do, or the things they need to work with in a particular space, and then build that. By way of a fairly simple example, here's a really typical representation of a website. This is a wireframe. There's a menu at the top, section one, section two, section three, section four. In a really simple sense, you can make UX spaces that correspond to these sections of your site. But you can also nest your UX sections. You can create reusable UX spaces. You can place them in different sections, move them around. I think you can probably already see that this is starting to correspond to components that Drupal gives you, like panels or blocks or other systems. Finally, UX spaces are easy to document. This is pretty important because you need to be able to share these with other people. You need to be able to talk to other people about them. You need to be able to work through some of these ideas with users as well, potentially. Here's an example. We've talked about park life very briefly. And this is a really simple documented UX space for a park, a park UX space. It contains the entity park. Parks represent a physical park or garden. And a task, a user can search for parks. I'm going to talk more about this example later. This is just to show you what it looks like. It's similar to UML or entity diagrams. If you're familiar with those, you'll notice one of the differences is we don't draw relationships between objects. We actually put a bound around them instead. This allows us to do things like overlap bounds. You can also hand draw these, which is quite nice. This is just taking some of the content out of that one and just showing you the components, an entity and a task. There's a little foldy document for an entity and a little strike box for a task. You don't have to do that if you don't want to. It's just the way I'm representing them today. We can also do things like imply relationships with other entities. So let's have a look at another example. This is for a project that hasn't been built yet that allows users to add motor vehicles to their garage. The idea here is that a user can track their motor vehicles and what they're doing and when they need to be serviced and various other components. This is the garage UX space. This has a vehicle, has a relationship with a user. We might want to draw on that later. And it has a task. A user can add and remove vehicles from the garage. It's really not fleshed out at this point. We can start to ask questions about what a user is going to want to do. What else do they want to do in their garage UX space? UX spaces can be nicely overlapped as well. So when you're documenting them, you have to put individual entities into different spaces and see the overlaps start to draw relationships between them that way. We can also document users fairly simply and we can make them entities as well if we need to, if you need to search users. So it's quite flexible and you can do what you like. Anyway, I'm going to give you a quick test because we've looked at it now. Well, I have a glass of water. Have a look at this one. See if you can tell me what it is. Which site is this? Very good. It's Twitter. I had to pick something easy, right? Because there are really complicated UX spaces that are quite hard to work out backwards. What about this one? What gave it away, was it? Sure. All right. So I think you've got the hang of it. Cool. So UX spaces for Drupal. And this is kind of the key here. We've talked about a methodology that's fairly general. You could use it on any site, but why are we actually talking about it in the context of Drupal? Well, this is not a situation where I came up with an idea and thought, hey, this would work really well for Drupal. I actually ended up combining a whole lot of different ways in which I'd built sites in the past to come up with a system that was workable and could be implemented in Drupal. UX spaces give us an opportunity to bring Drupal's strong content model to the fore without dropping off some of these other processes which are important. It's really easy to translate some of the UX space concepts into Drupal, content is entities, active is the users, and then the behaviors are the specific things that users need to do. You just kind of break down into two areas. You've got tasks, which can be things like filters, sorts and flags, things users actually need to do in order to complete something. And then you've got interactions. These can be things that a user might observe or might have the opportunity to interact with, such as a slider or a video or something else. And once you've actually done some UX spaces, once you've completed some diagrams, you can translate those really easily into individual components that you can deploy on your site. You can use mini-panels, view modes, views, blocks. It's all sorts of different ways in which a UX space can be represented. A section of a site through a menu also works. So the first one of these things is content. How do you get your content structure? Well, Drupal responds really nicely to content modeling. You can derive content from a content modeling exercise really easily, writing down the properties of your content, what sort of fields you need. It's quite easy. Some content may already exist in your project or some may emerge from any user requirements that you do. Typically the content structure exists prior to the user requirements quite frequently. Sometimes user requirements exist prior to content structure. Content types can also be defined from your product, and that can be a saleable product, an information product, a service product. You might draw additional objects from your business structure. I'm not going to go too deeply into these subjects. They're really for a different time. In the case of Parkfile, we have one type of content, and that is a park. It's the only type of content we're really interested in. We'll come back to that. In order to make this process work, you need to have segmented your audience in some way. You need to have worked out what the actual needs of your users are. There's lots of ways to define your users. There's an entire discipline called marketing, which is about this particular process. And if you don't know anything about it, I strongly recommend picking up something like the Principles of Marketing by Philip Kotler, which is a university textbook, and reading the stuff on segmentation because it's really, really useful. It will help you work out some stuff about your users, even if you never touch it again. Anyway, lots of different ways to do it. Behavioral, demographic, information needs, service requirements, geographic. Demographic relates to things like age, sex, religion. Anyway, an audience is basically the smallest group of people who you can communicate with with the same channel and message. So those are the ways you break them up. Now, you might come out of this process with personas or user groups or stakeholders or however it is you're defining this. But you'll find it hard to do good site design, good user experience design, without having done some sort of breakdown of your audience and what you need. You need to test it. You need to do all sorts of stuff to get that right. But there are ways you can do it. Parkfile has three audiences that we're concerned about in particular. And they are the tourists, the sightseers, the ones who want to find parks and gardens for their historical or interest or beauty. We've got families. Families are interested in places where they can take their kids. They're concerned about safety and barbecues and things like that. And then there's people who want to exercise. So they're going to want to know about which parks have running tracks, which parks are good for jogging, which parks aren't good for jogging. Where can I go for those funny parks with the little wooden setup machines? Those kinds of things. And the final item there was behaviours. I've talked a little bit about this already. Behavours are things that can be broken down to tasks and interactions. I've toyed with this one a bit. I think it's a fairly arbitrary distinction. But it's something to think about. Examples of behaviours, things like flagging content for bookmarking, social sharing links. And my feeling is that behaviours will tend to emerge from user stories. So there was a section on user stories which I think I've taken out. User stories are a way of describing things that a user needs to do. As a family, I want to find safe parks so that I can let my kids run around while I have a glass of wine. That's a user story. And you can sort of extrapolate a whole lot of information from that and you can place it in your UX space. So let's look at how we do that. We're going to do a worked example. We're going to do park file. So as we said before, park file is a guide to parks and sporting grounds. Users can find parks which match their interests or needs. They can rate parks and gardens. They can add parks to it. So let's talk about who our audience are. We've got our sports and fitness crowd. They're looking for the best parks for running. We've got our families. They're interested in picnics, barbecues, kids' activities. Concerned about safety. We've got tourists. They want to know about sight-seeing opportunities. Probably also things like public transport. Good chance that tourists don't care about whether or not they can take their dog unlike families. So we can represent that fairly easily. We just place the book. Sorry. We basically just draw four boxes. Three boxes. Three boxes. The family audience, the tourist audience and the sport and rec audience. We've sort of said what they're interested in. Family outing, sight-seeing, places to stay. We've also documented what entity type they are because we're going to build it in Drupal. Next we've got our content. And now we're looking at parks. So a really rough description of a park because it's got a title and a description and a location. We also say it's going to have some way of classifying it. We need to know whether it's good for sporting activities or sight-seeing opportunities or family activities. We haven't really defined our taxonomies yet but we kind of know what these are going to be. Anyway, let's try and put this into a user space. We start with a really basic park UX space. We're going to stick in our park. Parks represent a garden. And then we're going to add a task. This is a user story. This is kind of the glue that holds it together. We're going to search for parks. Hey, I do have a bit on user stories. How about that? The user story is as a role, I want goal desire so that benefit. As a member of a family, I want to be able to find safe parks so I can have a glass of wine. So there it is. There's the user story. If you're doing agile development, this ties in really nicely with agile because all of a sudden you've got user stories defined. However, there is a bit of an assumption here. There's an assumption implicit in this task. What is the user searching for? Why is the user searching? So far, all we've really done here, if we translate this into part of our site is describe a search page. So we need to go back to our users and really find out what they're looking for. So let's just recap on our audience. Here are the identifying characteristics of those groups. Family outings, sightseeing, sports or exercise. These come out really nicely to a Drupal vocabulary we can call interests. So let's add that to our diagram. So now it's changed a bit. A user can search for parks by interest. We've added the interest. An interest represents an activity to be undertaken at a park. We've just noted that it's a taxonomy term. We've also renamed our space find by interest. And because we've done it this way, because it's Drupal, we can start to see the way in which we're going to build these relationships out. So let's look as a content type. The taxonomy is an interest. And really simply that's a term reference. Find parks by interest makes a really good section for our website. We might change the name of the menu item ultimately because maybe that's not quite the right term for what we're trying to do. But given the basis of how our site works, what it's meant to do, this makes a pretty good homepage. I'm not going to go into too much detail about how you might implement this. But once you start flushing it out, you might decide on a list of teasers and an interest drop-down. That's pretty simplistic. And I realise that probably wouldn't solve the problem that we're trying to solve here. But with that UX space, you can go and develop something more fully. There's other potential user spaces we might want with Park File as well. We're probably going to look at geographic search, geolocation, find me parks near me, get the information from the browser We want to look at user spaces for contributed parks. We might want to look at user spaces for social touchpoints or favourites or ratings. We can determine some of this stuff from what we've got out of our user research. So there's the user centre design part coming in. You can go back and iterate over this process anytime you like. Anyway, I've fleshed it out a bit more for you. So here are four user spaces. Find by interest, find by location, view parks and manage parks. It's not a complete diagram, but it's getting there. Find by location uses location taxonomy. It's similar to find by interest. Maybe we should combine them. Looking at this looks to me like they could well be combined. That's good. Combine them and try again. We've got a specific user space for viewing a park. This is like your node view page for a park. You can rate the park. A user can review details of the park and a user can share the park through social media. All right. We've got some more questions we can ask. What is the ratings axis? What are we rating? We probably need to do more work here. That's fine. Go into it. Add to favourites potentially implies five star, a social toolbar. Who knows? Finally, you've got manage parks. Here is where you can add a new park. You can claim an existing park. We've already worked on. Can both of these be done from the same screen? Maybe. Maybe not. Try it out. With a UX space like that, you can start to translate those into wireframes or site sections or builds fairly easily. Building it in Drupal then is the hard part. And that's for you to work out in another session. All right. So quick review. UX strategy for Drupal sites. There's some common pitfalls and you can overcome these if you really take a unified approach to it. And the trick here is to make sure that you're including the way Drupal works in your process. So you can start with user-centered design activities, IA research, content modelling, and then try and merge these together by documenting them in UX spaces. I find turning the UX spaces into wireframes is a really good next step. Because that results in a bit more of a clear build idea. But you don't need to do that if you can relate them in your mind or your head. Then you can just build it. You can sit down with your Drupal site. You can start building. Maybe you've decided you've got four sections you need to build. So you build the sections. You make sure you can accomplish the tasks and the sections with the tools you've got. Maybe you decide you want find by location to do a whole lot more. Break it out into a separate space. Put new UX spaces inside it. Make them blocks. That's it. Thank you very much. Yeah. So your question was when do you add the authors? Do you mean the authors of the content? As an audience? Well it depends, I guess your authors are either going to be creating content for the audience or it will be user generated in which case they're part of the audience. So I generally wouldn't personally include an authorial concept. Unless I was looking at working on the user experience of the authoring process. Yeah. Which was probably perfectly valid. But I haven't actually come across a project yet where that was a really strong requirement. I think partly because as time goes by, Drupal's authoring tools slowly get better. So even though people complain about them a bit every time there's a minor improvement it kind of shuts them up for a while. Yeah, absolutely. Yeah and I think if you look at this particular diagram there's a manage park section. We're sort of assuming in this site that we're going to have authors creating content that are going to be the actual users editing our parks. So there is some consideration of that there but only in terms of them as an audience with authorial capabilities. Yeah, so the question was basically if you're making changes to your design or your implementation, should you A-B test it? In a perfect world, yes. Probably should. I'm fairly data driven when it comes to users. I like to actually see what they're doing and I like to know that the assumptions we make about them are actually true because I usually find that they're not almost uniformly they're not. One of the first things that I usually find with a site is that the audiences that are defined by the people who are making the site or commissioning the site are actually completely different from those people who use it. The way people self-identify is different. An A-B testing falls into the same category. You might think a change is really good. You might decide that combining interest and location is really good but if you're actually able to test that properly when you do it that definitely tells you whether you're right or not which is ultimately more important in this process. Does that answer your question? I think both are valid. I just produce inconclusive results in my experience especially on sites that don't have a lot of traffic. It's very hard to get... Does everybody here know what a standard deviation is? If anyone doesn't it's basically a standard deviation on a set of results from a test tells you whether or not the result that you got was actually significant in terms of the group. And with very small groups of people there are really wide standard deviations. So you find that a lot of the time you can't draw conclusive results from your tests even if you looked at a graph and it looked like there was a certain thing that might all be inside a standard deviation which means no statistical difference between them. An actual fact, maybe you've made a change and it hasn't made any difference at all. You might retest in three months to get a different result. That's my experience with it anyway. I think people might have different experiences. So the question was how do we decide when to use which part of Drupal or custom development based on the design. I think we have a lot of arguments about that. Definitely where I work. Previous Next uses an agile development method where developers get a high degree of input into the way in which they solve problems. So we frequently have arguments about how best to actually implement something. I think the thing with Drupal is there's often a simple solution to something and you should always try the simple Drupal solution first before you go off and try and do it yourself. But there's kind of a grey area in the middle where the simple solution almost works and that's when you have to start making business decisions and get the business owner in to work out whether you want to spend a week doing the custom thing or get the thing that's almost what they wanted but it's a bit different. That's the only real way I know to solve that problem because you've got to find a way of deciding it some way. If it's your own time maybe if it's my own time I might sit there and write the custom thing just for out of interest but people don't tend to want to pay for that sadly. Good question. The question was how do you actually make relationships between UX spaces work from an end user perspective when they're on the site or in the app. I think it comes down a lot to sort of creative problem solving in that case. Sometimes an overlapping user space in the case of the diagram it's up on the screen really just represents that that park is featured in all of them. What that might mean is that when you're looking at a park you might provide a set of contextual tools that link through to all the things you might want to do in a park maybe filtered down by what the user wants to do. If the user spaces are wholly contained then you can look at maybe having a block that fits within other user spaces so you can correspond to user space to a block. You might define a whole kind of ratings user space which you can then insert into other spaces. There's no real, I don't really have a shorthand for that at the moment but it'd be easy to do. But I think it's a creative problem solving task when you see an overlap. Sometimes the reason for the overlap in my diagrams is merely to keep everything on one page. Because it's easier to see everything on one page than it is on five pages or four. Any other questions? Sorry, before I go I'm just going to do a quick plug for two boffs. There's a link data boff, 345 in the Lady Penron Room and Drupal for Government tomorrow morning. And Rate My Session on Sydney2013.drupal.com Thank you.