 My name's Christopher Schene and I'm going to be talking about UX Spaces, which is an approach that we're using at my company previous next in Australia to do UX, or try and do UX a bit better. What I'm going to cover today is a bit of background on user experience because this is really, this is a site building stream and I'm aware some of you may not have a clue what I'm talking about, so that's cool. Some of you may be UX practitioners and might understand some of this already, so that's fine. I'm going to talk about why traditional user-centered design and UX processes break when applied to Drupal and a lot of other CMSs, to be fair. And I'm going to give you some ideas about resolving some of those issues, combining user-centered design, content modeling, interaction design and a few other processes. And I'm also going to go through a bit of a worked example. Basically what we're going to be looking at is a technique that we call User Spaces. And there's one up on the board behind me at the moment. User Spaces are a really simple way of representing kind of low-fidelity task spaces for users and they're a way of bringing various different disciplines together in a fairly simple methodology that most people can understand. We're also going to be looking at a fictional example called Parkfile, a website which helps people find parks and gardens for whatever reason, just to give you an idea of what I'm talking about. And there'll be time for questions at the end. So a little bit about me, just to begin with, I'm a professional Drupal consultant. I've been doing Drupal since 2007 exclusively and I first worked with 4.5. We've come a long way since then, which is good. I'm not actually a web designer by trade. My background's in marketing, humanities, the arts, photography. So I kind of got into this by accident. But I really love Drupal and it's been a really great, great time. So right now I work for Previous Next, who some of you may have come across before. We do a lot of work on Core and we're Australia's biggest Drupal firm. And I'm based in Canberra, so I do all government work mostly. Okay, so the Drupal problem. We're going to start with the Drupal problem. Drupal is opinionated. Drupal's going to make you do things you don't want to do. Drupal makes you build sites in certain ways. It makes some things easy, but it makes some things very hard. If you are inexperienced, experimenting, trying new things, doing something even for an experienced person that you haven't done before, you can get caught in traps. You can get caught in a sea of modules. It's lots of different ways in which you can kind of trip up on Drupal. And Drupal is hard to design for, for a number of reasons. We'll go over this in more detail later. But fundamentally, Drupal's going to push you around. It's going to make you do things you don't want to do. But let's back out of it. Let's talk about the bigger UX picture. Why are we here? What are we here to do? What is user experience? This is a bit of a tough one. User experience is kind of an umbrella term for a lot of different aspects of how we interact with a website. It's concerned with making the process of using a service engaging relevant and enjoyable, but it doesn't tell you really what it is. It encompasses information architecture. It includes usability. It includes interaction design, service design, a whole range of processes and methodologies. Sadly, that doesn't tell you how to do it. Basically, if you're engaged in any aspect of site planning or building in any way, you're part of the UX process. UX is not something that we shift off to a separate part of the team. Everybody has a role to play in UX. Often, the UX ideology, which can be quite prevalent in some development environments, is placed at the centre of how the projects are delivered. So we might produce briefs that speak of user-centred design or agile development or other ways of creating really engaging digital experiences. But sometimes when our marketing people say this, we don't actually know what that means, and neither do they. They have to say it, right? So while we agree that it's important and it's a core part of our work, some of us don't really understand it. We don't actually understand what we're doing or why we're doing it. There are some people among us who get user experience. They've understood its methods, they've worked out how to do it, and a lot of them do really great work. They can, you know, we're not saying that user experience is impossible. We're just saying it's a bit fuzzy. But people work in a lot of different ways and they're not always compatible ways. Competing specializations can be really hard to reconcile sometimes. The designer can't talk to the developer. Neither of them can speak the same language as the client. The interaction designer and the information architect are in a room, stabbing each other with whiteboard markers. And in addition to that, different project methodologies don't always work very well together. So your agile development process doesn't work with your functional specifications and your iterative design approaches are cloned by waterfall timelines. They don't always work together. How do you find ways to actually make them work? My theory is that the reason that these things are hard is not because we don't have ways to do them or we can't find ways to do them, but because nobody's actually really come up with a really good way of doing them yet. And I'm not going to claim that I've got that solution today, but this is the way we're trying to solve that problem and you might find this useful in your work as well. Anyway, there's kind of three approaches to user experience. This is my experience of user experience. The first is business-centered. For better or for worse, business-centered user experience, which crops up a lot, focuses on the structure of the needs of the business, tends to be heavily driven by business requirements. These can come out of strategy, business strategy. High-level site architectures often map to business structures in this environment. User needs are often subservient to the business model and it tends to produce pretty boring sites, but we've all seen them. There's lots of them out there. We might say that this is almost an user experience anti-pattern, if you like, but it is a way in which we work. The next one is actually what we call user-centered design. This focuses really heavily on the needs of users. It's driven by the requirements of users. Information and content structure tends to be quite subservient to how users want to do tasks, which can be a problem. Business structure tends to be irrelevant, that's fine. This can produce really great outcomes, but it can be really hard to implement, and we'll talk a bit about that shortly. The last one is content-centered. Drupal really excels at content-centered design. This is an approach where your structure, your interactions, they're all driven by the content. We sort of hope that content's driven by user requirements, but it's not always. Sometimes it comes out of business processes and things. Drupal's really good at this because it's got entities and views and lots of ways to take content and sort of repurpose it, but it doesn't necessarily mean that it's producing a good usable site. So, can we bring them together? We want a unified approach. How are we going to bring together disparate strands that might happen at different times and produce a good outcome? Does anybody know who that is? Anyone in the room, a user experience expert who knows who that is? We've got two hands. Brilliant. Three hands. Four hands. This is Jesse James Garrett. Jesse James Garrett wrote a book called The Elements of User Experience. He's kind of like the godfather of user experience, and he looks a bit like the godfather as well. Is he here? No, good. The Elements of User Experience, which is a really good book, by the way, it's basically a process for getting from a set of requirements to an implementable design. So, starting at the top, we start with our user needs. We go from there to build a spec or requirements. Then we work on our interaction design, our information architecture. Then we look at interface and navigation. We do the information design, wireframes. Finally, we get to the surface or the visual design. That's fine. It's a perfectly good process as its limitations, but it's quite good. However, often we don't do it the way he said we should do it. We do it a different way. We swap processes around. We remove them. This can happen for a number of reasons. Sometimes it's just that your team doesn't work that way, or you've been given requirements from somewhere, or some other part of the project has come from a different part of the business. And there's a fundamental step at the end, which is actually quite hard, which is to build it in Drupal. And this is an added complication, which if it only comes at the end, is going to make your life really difficult, depending on the project. And that's how I've come to the pitfalls of user experience. We're going to talk about how Drupal doesn't match these processes. So the first problem you're going to find is that Drupal's markup may not match the design. Drupal provides its own default markup for everything. So if you've got other markup, or markup that needs to be sufficiently different, then you enter a process of customization, which can, in itself, be problematic. Now, if you know what you're doing, you may be fine. You also may run into problems. Another issue is that Drupal's fairly structured, but sometimes designs are not. The designs may mix Drupal components liberally. They may combine entities and menus into a single visual element, which might be quite hard to build. The other corollary of this is that the design can be inconsistent. The design can have changing menus and changing behaviors of objects, which can be difficult to set up with Drupal, because Drupal tends to be quite consistent. If you want a menu, it tends to be the same everywhere. A more extended version of this problem is when Drupal doesn't actually have a solution for the kind of thing you have to do. Sometimes you find that things get handed to you sort of partly implemented, and these can be built with JS libraries that Drupal doesn't really support. Or they might be features that Drupal has, but you're expected to do them differently. And this is kind of what happens. Things take longer, they cost more, things get rebuilt, people get unhappy. So why does this happen? Well, fundamentally, I think this is about process. So depending on the orientation you approach UX with, you'll do these steps in a different order and with different weightings. So what we've tried to do is come up with a way of combining some of these steps together. And we've come up with a thing called UX Spaces. So because this is a site-building talk and not just a theoretical discussion about user experience, I'm going to be talking about the methodology behind UX Spaces, and I'm going to be showing you a little bit how we can use this to put together a site. UX Spaces are a way of thinking about the needs of the user. They're a way of thinking about the information you're presenting, the overall relationship between the different interactions that exist on your site, and how they play together in the parts of your site. Now, when I say site, think app, think mobile app, whatever you like, their umbrella terms. What I'm going to say might sound kind of prescriptive, it's really not. If you find some of these ideas useful, run with them, take them, see what you can do, come up with your own versions. It's pretty low-fi, so it's not too hard. Anyway, UX Spaces represent the aspects which are required to make a site useful and functional. We're trying to catch the three things. We're trying to catch your content or data. We're trying to catch your behaviors of things your site does. These are a bit fuzzy. They're sort of interactions and tasks and things that people need to do. Finally, we want to consider users in this process. We want to have a bit of visibility on who the users actually are. You can call these things whatever you want. It kind of doesn't matter. They're all the same. UX Spaces are really a communication and planning tool. We do them before we start building. They're easy to implement on paper. So I've used a tool called OmniGraphil, which some of you probably use, just to do up some really simple diagrams that are a bit easy to see on the board. But you can do them on a napkin if you like. It doesn't matter. Anyway, the idea is to create a boundary around a set of interactions that are required to do a specific task that are logically grouped together. So because we're doing that, we're looking at relating the actor or the user with the content. We can define a UX space by the intended audience, the type of content, the required interactions. These are all constraints which narrow down what each UX space is going to do. And because these were actually developed backwards from Drupal site builds, they almost always correspond to components you can build in Drupal. Now, that may be a panel, or it might be a block, or it might be some other space that you can build. The most simple representation of a UX space I can give you is that in a website that has four menu items, each one is itself a UX space. This is a case where we're creating a space where people need to do certain things that are logically distinct. But UX spaces can be nested. There's no reason why you can't do that. It's all generally speaking. But fundamentally, they're easy to document. So here's an example of a UX space where a user can search for parks on our sample website park file, which is a site which allows users to find parks and gardens for exercise or picnic or a barbecue if you're in Australia. Do you have barbecues in America? Yes, somebody's nodding. Good. Cool. I think we decided the other day that was called char broiling. Is that right? Is that right? Did I hear Burger King? So this is what we've got in this UX space. It's basically just defining the entity and the task. That's all it's doing. So the entity is the park. Parks represent a physical park or garden. And the task is a user can search for parks. This is really simple, this one. We try and define our tasks for most of our work as user stories. That's how we work. We do agile. You may have other ways of doing it. For those of you who aren't familiar with user stories, user stories are a way of expressing a business requirement as something that a user needs to do with a benefit. So as a family, I want to find safe parks for picnics so that I can enjoy my lunch knowing my kids are safe. So that's what we've got there. The simplified version of that task for this particular example. I'll come back to that later. UX space is pretty easy to link to other ideas as well. So you can do sort of UML style linking if you're used to that as a way of expressing them. In this case, what we're doing is we're expressing the user that's actually going to act in this space. And that's important because what we want to do in these UX spaces is bring in the actual requirements of individual user groups. Not just the concept of a user, but that's what I've got there. So this example shows an app which allows users to keep track of their car and their service history. So we've got a user, a user's a registered user of the website. They've got many vehicles. In their garage UX space, they can list their vehicles and they can add and remove vehicles from the garage. It's pretty simple, this one. If you like, you can get fancy and start overlapping your user spaces. You can start to find relationships between them. So these types of spaces can help you work out where you want to combine UX spaces to do different things or cross-link between them. Anyway, I'm going to give you a quick test. Have a quick read of that, see if you can tell me what website it is. Shout it out. Very good. Here's another one. The next one's really easy. I kind of gave it away with the... Yeah. So this process was developed for Drupal. But it's developed for Drupal. So let's apply it to Drupal and have a look. Just to recap, we're looking at content, behaviors and users. So what are they in Drupal? Most of you should know this, but we'll go over it anyway. Content in Drupal is really simple, but content for UX spaces sort of covers a few more things. Content types, taxonomy, commerce entities potentially, flags, anything that's an entity and sometimes things which are not entities or content in UX spaces. Most of the time you can work that out. It's not too hard. I often try and tie this with some kind of documented content model. If I just hand out a content model like this to designers and developers, they look at me like I've got rocks in my head. But if I give them a UX space and then say, when you're ready to build that, here's the list of fields. It's usually much easier. Content types can often be defined from a product as well. Or they might come from your business structure. Finding out where they are and what they do is part of the process. The park file, we've got parks. Does anybody know what that park is? It's at Rose Gardens, yeah. Did visitors to Portland know that Portland has like the Rose Garden? The world's most famous Rose Garden? I didn't. I still have to go. Users. Now, we know what users are in Drupal, but in this case, we actually kind of want to know about specific kinds of users, what they're going to do. Segmentation, personas, information that tells us actually what our users want, why they're here. There's a lot of ways you can do this. You can break up users by their behaviour, by their demographics, their information needs, their service locations. It doesn't matter. The key, however, for user spaces is that you're trying to define groups that are mutually distinct. So in terms of segmenting your audience, you want to follow the marketing rule of thumb, which is the audience is the smallest group of people who can be communicated with using the same message and channel. If you need to change the message or you need to change the channel, then you've got a different group. Representing users in UX spaces is pretty simple. We just put a box around them, what they can do. I usually make anonymous users have a dotted line around them because it's a bit easier to differentiate between them. For Parkfile, we're going to have three groups of users. We're going to have tourists, people who want to go to famous parks like Versailles, families, people looking to hang out in parks with their families, and people looking for sports and recreation opportunities. Finally, behaviours. Things. Tasks and interactions. It's a bit fuzzy, but more or less, a task is something a user has to do to get to their goal, whereas an interaction is kind of just a thing that might happen. A YouTube video that they don't have to watch is more of an interaction than it is a task. It's up to you to define how you want to do that, but I make a little bit of a distinction between the two. Sorry, all the fonts are wrong and it's hard to see. In Drupal, these can be things like flagging content for bookmarking. They can be exposed searches and views. Often when we build a view, we just kind of drop it in and we add a filter and we do this and we do that and we think okay, that looks great. UX Spaces actually gives you an opportunity to talk about what the user actually needs to do for a given view. Pardon me before they get to that point. It could include social sharing links, could include commenting. Finally, when you've got your spaces, these translate into Drupal things as well. Panels, mini-panels, views, blocks, content panes. Often you can see what they're going to be once you've got them documented, even if it's not clear how they might fit together to begin with. Let's talk a bit more about Parkfile. Parkfile is a guide to parks and sporting grounds. Users can find parks which match their needs. We've got parks and gardens. Who's our audience? First of all, we've got the sports and fitness group. The key details here are that they're looking for places where they can go running, where there's exercise equipment, where they can play what we call soccer. What do you call it? Good. We've got families. Families want picnic, barbecue facilities, kids' playgrounds, but also if you've got little kids, it's important. You want to know that there's a lot of creepy people around and that your kids aren't going to run on the roads. Finally, you've got tourists. Tourists are into sightseeing, public transport, hotels. Tourists are going to come to the Rose Garden. This is how we represent that in Drupal. We've got our family audience, our tourist audience and our sport and rep audience. Next, we've got our content. These are parks. I've just put a few of the fields we might use in Drupal for those parks. But often you won't get to a field definition at this point. You don't really need it. Let's start to build up a UX space where you'll add our park type and we'll add our user. A user can search for parks. But there's a bit of an implicit assumption in what I've done here. What is the user searching for? Why is the user searching? Looking back at our audiences, these three groups all have things that they're going to want to do. Things that they want. These are the three audiences that we represented. Family, tourist, sport and rep. And these are the identifying characteristics of the groups that I've added to these. So now we can add interests to the diagram. Interests are a term and they're part of this UX space. We have the beginnings of a good user space and we can call this find by interest. A user can search for parks by interest. Because we've described our space as entities and tasks, we can actually work out how to build this pretty easily in Drupal. I've put that on the side in case anyone needs a little bit of help with that. A park is really simply a content type and interest is a taxonomy. So the simple way to build that is to build a term reference field. I know this possibly seems like Drupal for dummies for some of you, but find parks by interest makes a good section for our site. So we might change the name of the menu item. We might describe what this section does. Given that this is the basis of how the site actually works, this is also a good candidate for a homepage. So as we go, we can start to piece together by adding different user spaces together. We can piece together an appropriate user experience for our site. Now I've done a wireframe here. You may not do a wireframe. You may take your user spaces and push them to a designer. You might start to do a content-oriented build or you might combine a visual look and feel with a built-in Drupal. You can do it in multiple ways. I've just tried to kind of set it up so that it's easy to understand here. But as you do it, you're going to want to draw on the definitions that you've provided through your user spaces. We can add more user spaces to park file. Some of the other things people might want to do, geographic search. They might want to add their own parks, keep parks up to date because I don't want to do it. They're going to want social touch points and interactions with social media. They're going to want to add favourite parks. They might want to do ratings. So you might end up with a user space diagram that looks in a more detailed sense like this one. This is capturing four user spaces find by interest, find by location, view parks and manage parks. Viewing a park is about seeing the details of the park, rating it. What's the ratings axis? What's the rating? Opportunities to share. There might also be a way to add to favourites in there. Managed parks might be a list of parks. Because I'm sharing the same entity, I've actually just spread it out overall for user spaces on this diagram just to make it a bit easier to read. You can do it how you like. The next step and the critical step for what we want to do is to get this into Drupal. So I'm just going to pull out a couple of these and see how I would have gone about building them. Find by location. A user can find parks by location. We've got some kind of location mechanism, a taxonomy possibly, and a park. We're likely to go and use panels for something like this. We might be combining different elements. Maybe we've got a load of view into that panel that pulls up relevant parks by the taxonomy. We need some sort of way of viewing individual park in that list. So that leads logically to display suite. And we're going to be looking at mapping because it's a location thing, right? So geofield, open layers, some kind of combination there. Did anyone go to the layouts talk? It was a thing on layouts yesterday. Did they have a good Barney over where we should be using panels or display suite? I'm a display suite 6 maintainer, I'm opinionated. This is the user space for viewing a park. This is what we know of as node view, basically. Just document it a bit differently. Display suite with a full view mode. We're probably looking at image styles because it's their parks, right? People wouldn't look at them. They're going to want to see photos. We might add light box 2 in there unless accessibility is important to us in which case we won't. We're going to be looking at ratings. We're going to be looking at the voting API. Some way of capturing what people think about the park so that we can share that information. And finally, just looking into social networks without this or something. These are not necessarily modules that I recommend you use. They're just modules that are obvious for this kind of use case. And here is managing parks. This is a user space that allows a user to see all the parks which they're able to edit. Parks they've added or parks they've claimed. They have fairly compact lists of parks. Again, that might be display suite but it could just be views. We've got to bring in node ownership which is a module which allows users to claim nodes owned by an anonymous user or other users. This also implies the use of some permissions as well. Being able to add new parks and edit your own parks. So that's it. That's user spaces for Drupal. We're basically trying to solve some common UX tasks through a really simple approach. I hope that I've explained that to you in a succinct enough fashion today. I was aiming for 30 minutes. Basically, start with your UCD activities, your IA research, do all the information gathering you need to get yourself to the point where you can start documenting your user spaces. Work through them until you feel like you've got enough to build a site and start moving. There's a lot of different ways you can extend your spaces as well. These are just some of the ways that I know people have got into them. One of them is constraints. Some people find it quite useful to say what a UX space doesn't do as well as what it does do. UX spaces because of their... because of the way they work, the way they look, combine really nicely with mood boards or other sorts of design activities. You could use a single sheet of paper for each UX space, for example. Stick all your mood board stuff on there. UX spaces also morph kind of nicely into wireframes up to a point. I think the Google example was probably a good one. Doesn't always work. The other thing about UX spaces is that they originally came out of a pseudo-UML approach that we used to use for defining Drupal sites. One of the issues with some of these more rigid structures for defining Drupal sites is that they tend to focus only on, say, the content structure or some other aspect. They can be combined really easily with these approaches, which is nice. And finally, because you may be describing actually what has to happen in a UX space through a task, you can combine them with testing. So if you're familiar with Behat or other kinds of testing processes, you can write your tests based on these, even include them, and it's not too hard to produce a test for them. So that's it. We've got time for questions. Does anybody want to... Thank you. I think this could just be a matter of, you know, you're so good, you make it look easy. But... And I'm certainly not claiming that we do this exactly, but just looking at it seems so intuitive. Could you give us a contrasting example of how it goes wrong? What do people do that is not this process? What do people do that is not this process? I think often I see situations where there's a set of functional requirements for a project, which is a list of what the project must do, perhaps not defined in terms at all of users, and maybe a design. And then they get handed to a Drupal team to build. That's where the Drupal team essentially has to do a second requirements analysis in order to work out how to build the damn thing in Drupal. If that was being built as, say, flat HTML, sometimes it would be easier, sans the dynamic bits. So in... I think the bigger your team, the more spread out it is, the more chance that you're going to end up in a situation where maybe these aren't working. But it does depend on who you've got working for you. You know, sometimes you have a person who's just really good at bringing it all together. And they're head, perhaps. I think as a consultancy, we often get projects halfway through. So where the client's already done all their requirements analysis. And that's often where we strike pitfalls. Anyone else? Nope. Yes. How critical do you think it is to actually do a non-functional wireframe? Well, these are non-functional wireframes, right? Yeah. So fairly critical. I don't like to then put it in this thing that looks like a fake browser and all that garbage. Not that important, actually. Some of the best designs I've ever seen never had wireframes in them. But they've been prototyped. And I think maybe prototyping is almost more important. But it depends on how how tight your actual final implementation needs to match some kind of concept of what needs to be done. So in a lot of cases, we can spin up a Drupal site, turn on a view, and that's actually all it's required. It doesn't need to look like what some designer thinks it looks like. Just because functionally, that's okay. That does the job. But in other cases, we're looking at very tight metrics around what each part needs to do. And maybe doing some sort of prototyping first helps. But you can also do prototyping in Drupal, right? Yeah. It depends on the project. And then a second question, I guess. This makes a lot of assumptions that you actually know your users. Yeah. So, you know, do you... I mean, are you going out and actually reaching out to the users to get that information, or are you relying on the spec from your client? It's difficult. Yeah. I do a lot of government work and my experience in government has been very difficult to get information about users. Very, very difficult sometimes to get anywhere near it. So often what you have to do is get around the subject matter experts for the area you're building and ask them. That's sometimes the best you can do. However, even sort of on the occasion I've had to verify what they think, that's often wrong as well. So... But I think it's good to have some idea to break it up some way. Even if you break it up based on some sort of behavioural segmentation. So you look at kind of... You break up the expected tasks rather than say things you can't really guess at like demographics or other methods. Okay. Thank you. Or you could just do a lot of A-B testing. Alright, thank you very much everyone. My details are on the board. Feel free to contact me.