 OK, so, grand. Got there in the end. Right, yes. Click. Yes. Right, so in my mind, 2015 was the year that all the designers in the world finally added the two letters U and X to the CV and the LinkedIn profile. Also, I would like to think that 2016 is the year that we bring it back to science. So, I'm Chris Pynnery. Hello. You may well know me as one of the more prominent busy bodies behind the Drupal apprenticeship scheme, but in my day job I am a consultant in UX and strategy. I've been using Drupal for 10 years now and unlike the vast majority of people in UX, I come from a more development background rather than a design one. I started building websites at the end of the 90s when all websites looked hilarious and a lot of the industry was people like myself who were freelancing and did the entire thing themselves. They did the design and they did the requirements gathering and they did the build in tables and basically we did everything. Then around the turn of the century I got a gig doing an extra net for the Peabody Trust and that was a place where like the Peabody Trust and the architects and the contractors could all like swap and just booted the computer. They could swap versions of plans for all these buildings that were going up in Silvertown and that really for me is when my job became, I guess that's when I started in UX although I didn't know it at the time. It's when my job as a web designer or web developer became more about people doing things, people achieving things, doing tasks, getting to places, getting information rather than any sort of artistic design. That's it, all right. Remember your notes. UX is different things to different people for a designer. As a designer it's a way that I can reframe my subjective artistic opinion as objective fact for front end coder. It's a way that I can spend three days of budget and messing about with a new CSS animation technique that I'd like to try out. Pulling your leg of course. But lots of people, clients mostly, tend to think of UX as interaction design or as interface design. While that's true to a certain extent and I'm not saying that those things don't matter, they're a part of it. Lots of decisions, especially early decisions around those sorts of things, interaction and interface, can to my mind be made, you can make wrong decisions easily. By making them too early. Already dying of thirst. Thinking about the strong things, interaction and interface, to me they're the icing on the cake of the product. While icing is nice, if that ratio is completely wrong and you've got 90% icing and 10% cake, it's shit cake. Also doing these things at the beginning, even if you're just thinking about them. It's good to think about these things, record them and come back to them later. Getting too involved in these sorts of things early on could also lead you to confirmation bias. You've heard of confirmation bias? Once you've got an idea about a thing then you will want to confirm that. The things that you will do, the investigations that you will do, the outcomes will lead you to confirm the thing that you already suspect, rather than being nice and objective about it. It goes further than usability as well. The fact that you can do a thing is different to the fact that you liked to do the thing and you enjoyed the experience of doing the thing. What comes down to behavioural economics in terms of money and a lot of modern sales psychology, the Challenger sale for example, they really support this idea with evidence that I haven't gotten any slides of. The way that you feel when you buy a product or you are in the purchasing process or the interaction process, the way you feel is much more important in terms of whether you will actually complete that sale or that action and whether you will come back. That's more important even than things that you would consider that you would postulate are more important like price and the value that you get back. That's interesting to me at least and also part of why UX is so important now because it's been identified with the value that puts money in your pocket. There are things that you can use UX for that help in design and development process. Having people to have a good user experience, you need to be testing that and to educate your clients into the fact that you want to be testing stuff earlier and more. It's good, but they are often scared of that sort of thing and they might not want to pay for it because they think why do you need to test it, you should have just built it properly. Putting things down and having measurement frameworks that are about users' needs, users' actions and KPIs and stuff that clients need and love. Having those about users is very empowering to the project rather than disempowering to the client. I don't know if that actually makes sense. I guess what I'm getting at is you do user research and the outcome of your user research is a bunch of data that then you get to communicate with your client about this data, about what you should be building. That's useful on loads of levels, not in no small part. It levels out stakeholders, so people are less likely to find reasons that their pet feature should go ahead when there's a bunch of data that says your pet feature doesn't help any of these users. It's just a thing that you want perfect. That's great. Come back to life. One moment, please. What that means to me is less talking, more clicking. Get through the slides really fast and then we'll go to the pub. The importance of data. Jim Barksdale, former Netscape CEO, has got this famous quote you may have heard. If we have data, let's go with data. If all we have is opinion, let's go with mine. In the modern world, or in my opinion, you rephrase that as if we have data, great. If we don't have data, let's go and get some data and make some good decisions. What's the problem? Weird slide. There's a bit of a rush. I'm googling what's the problem. Image search. Weird. It's hard to put it together. It's hard to suddenly inject user experience, discovery and testing into existing processes. People sometimes end up split up and siloed. The designers can do this UX part and they go off and do some discovery workshops with your clients. The danger of that is that if you're a non-technical designer and a count manager go off and do a big discovery session, generally what's going to come back out of that meeting is a big kick in the balls for the desk team. What we're trying to aim at is this idea of the multi-disciplined agile team working together from the start. I think UX is actually a good enabler for that because of things that I'll talk about in a second. You can get some common language around the things we do as developers and the things we do as UX practitioners. I got the idea from this session from a post that was on a list of part last year. I'm going to look up the lady's name because I've robbed some stuff from her. Sofia Vojcheovsky. Her post was about when she was designing an interface for the CNN presidential elections in 2012. She got into the project really late and then she had to design this mobile app that was going to follow the election. She had four days before development began and her boss says to her, I don't worry, the devs only need one template to start, so just design one template and give it to them. Then she freaked out because how can she design a page, a template in a whole system, designing one cog in a machine where she hasn't roughed out the entire machine. What she presented to them was this thing here, which is, essentially it's a system of objects. It's interchangeable, related parts of a machine. That's what she started to wireframe and that's what they took into the first sprint. Then they iterated on these wireframes of objects. Yes, exactly, but not in any great technical detail because she's a designer. It's like atomic design, this is what we're trying to push our designers towards. It's not like we're in charge of pushing them, but we're wanting to look at things at this sort of object entity level. This is quite a big deal to us, especially how we work in Drupal with entities. This is kind of what we're after. I think to mention the thing to avoid is just spinning around. Any sort of siloing, we understand that that's a bad thing. You don't want to have a designer to mock up this lovely PSD and then just hand it to a developer and say, now build this beautiful thing. In the same way, interestingly, at the Northern UX meet-up the other day, there was a guy talking who had come from a, he was a designer, but he joined a very technical build firm who had then got their designers in and the process was kind of reversed. They had, not now, but the thing he was talking about, they had their designers in a little silo and they would mock up loads of text up and then just say, design that. Both things are wrong and inefficient. Don't touch it. Sightmaps are a completely daft thing that people are still holding onto. They still do exist in the world and they're very important to bots. Especially when clients are telling you what their information architecture is, it's completely daft. The very best that you could ever hope for is how they see themselves in the organisation, in their organisational data, which is very doubtful whether that is going to be how a user wants to see a thing. Sightmap, nonsense, what we're looking for is elements, connected elements and prioritisation of the parts of the elements. Mike Atherton is thinking of mobile first, which is kind of adopted. Mobile first doesn't even really mean that you're designing for a phone first. What I guess has come out of the last few years of this is that it's really about prioritisation and that you are able to prioritise not only the elements of a process that you want to guide a user a lot, but also the objects that we're building and the parts of the machine. And prioritisation, forcing that into single columns is a grand idea. Going through processes like that, not only as a designer by yourself or as a customer even by yourself, but grouping that exercise and making that a group exercise. You have representatives from the development side, front end and the customer, then you're all collaborating on this idea of what is important and why, and you start to talk about these things. When we start to build something, unless we've built a resource library where all the resources already exist, then what we're working with is instantiated objects. What we need is a way to talk about these things that will be and the things that will be inside of them that works for everyone. That is what I would say is object-oriented user experience. It's to do with the discovery process really and I have been picked up by a couple of people on the slightly flirty title, whereas objects is the important bit rather than any more direct correlation with object-oriented programming. It's about putting object design over procedural action design. Not that that doesn't happen, but that it comes later. I've got a quote here from Mike Erston again. Thinking about a system through the lens of real-world objects in a user's mental model, products, tutorials, locations, not digital world actions, search, filter, compare, check out. This is the bonus. This is how we like to think and plan as developers. We want to know how object X relates to object Y and we want to know whether object A is comprised of lots of object Bs and what attributes will object X inherit from object B. Starting to talk about these things early on, I believe it's a really good foundation for cross-discipline communication and a discovery process that involves everyone from the beginning. Matching the user's mental model and talking about the objects that the user will recognise and makes the prototyping process easier, the build easier, you get simplicity and clarity out of that as well when you start to talk about things as objects and parts of things. Arguably, I mean dependent on the project of course, but when things start being objects right at the beginning then they become easier to iterate on because you're adding parts to objects, adding objects to objects rather than getting to the end of a process and then seeing that you need to tack something on. Also arguably better APIs should come out of this sort of approach of thinking about objects earlier on. You get loads of SEO brownie points as well because you can set up contextual cross-linking really easily. That I think is a really big win. This is a recipe site with persistent navigation footer and everything taken out. Just thinking about them as the object so we have ingredients and recipes and a chef. Then you can see that there's just infinite ways to loop around all of this content as a user and all the extra investigations that you could do around those things by changing the priorities of these things and seeing how that influenced user behaviour and user satisfaction. The amount of stuff that you could set up and test is incredible. We developed thinking about objects but designers tend to think and design procedurally. The object-oriented interface design is not a new thing. This book is from 1995 where it's an entire book advocating the whole thing. You can't wonder what happened. Why did we even stop designing in this way? I have a half-ass theory that when we got into the early 2000s and everybody must have a website and there was the big boom and lots of agencies who had been used to doing a visual graphic process then they just repeated that process and they had that relationship with their clients and they wanted this design review early stage whereas it really ought to come a good deal later. Talking about a process, a practical way of implementing this sort of thinking, this sort of working. This is a brief whereby I've written this thing out. The rules of presentation, don't put loads of text on a slide and then don't just read out your slide. I'll just do that. Give DIYers an outlet to post their home improvement challenge, soliciting potential solutions from product companies, brands. The DIYers get expert solutions from their challenges and brands get exposure. That's the platform that we're building. DIYers can search and browse existing challenges commenting on the proposed solutions. Brands can search and browse for open challenges that might be a good fit for one of their products. The DIYers can close the challenge after a solution has been chosen, later follow up on how well the solution worked. Brands can create a library of solutions that can be reused for various challenges. That's the client's idea helped along into a succinct way of explaining what we're going to build. Step one of this method is extract the objects from the goals. You can just highlight all the nouns in the key deliverables and the goals that you're after. It's not just highlighting nouns. There's a process of talking about what you're doing as well. Exposure is a result. That's not a thing that we're building. It's the result of what we build. We pay more attention to nouns that keep popping up, like challenge and solution. Ones like library, that's more of a list rather than an object, a list of objects. We're not too concerned with that. We can infer an object from the actions of commenting and following up. We need some sort of comment object. The challenge object will need multiple states of posted, in progress, closed, has feedback. Once we've got these objects, this has got a professional. We'll pull out all the objects on one colour sticky. Then we can start to pull down all the other objects that live inside these objects, the fields. Name, profile pic, short bio. You can't really see it here, but then I've got yellow post-it notes for the core content. Blue ones for metadata. What this ought to do as a group is provoke loads of really interesting conversations about what you're going to build at a very early stage. You're talking about what particular field should go in. I would put as much down as possible, and then if you don't agree on a particular field or a particular thing that ought to be there, then just question mark and then you can come back to that later. Can anyone even read them? It's good. This is step header, step description. In the solution, I'm imagining that there is some sort of step solution, and each step has a header or description and maybe an image. I've just stuck them together and made a note that there are things that might be repeated so they might have step one, two, three, four. It also provokes other conversations about things that may not have been in the brief, but may be really useful for users. Should a user be able to add a budget to a solution, is that useful? Do we want to do it? The next step of this is re-adding the objects as objects inside. Now we're talking about how these different objects relate to each other. It's not enough just to put a brand here, but there's a discussion around how the brand is an object inside a DIY profile. Exactly. What the red inside red is representing and being talked about is the relationship between those two objects. This is before we've done any drawings. We're talking about it as a group before someone has drawn a picture of how this already relates to another. When you get in a more water-fully process where you get a design or you get a wireframe handed to you, then as a developer you need to reverse engineer that and get all the objects out of it. What I'm suggesting is to just skip that step or do this bit first and then the wireframes can be wireframes based on the conversations that you've had about it. The next step is when we start to do the prioritisation, which is important from the user experience and also the grand conversations to have with clients as well, because then they're getting by and into the process and their understanding about how people will interact with their products becomes more evident. This is quite arbitrary the way that I've done this. It's more just for the effect of what I actually think is the priority of importance. This is not necessarily the order that things would be displayed in. This doesn't translate directly to my mobile app. When I'm looking at a DIY it goes, no, and then there's a profile pic and then this is all in one column. It's just about the prioritisation. Everyone's agreed and understands about the priorities of these different things before we go into the further stages. Then how this relates into Drupal is I think it's kind of clear that this is the way that Drupal wants to work. Having entities that are related to other entities across the board. Doing exercises like that with moving all the posts around, I guess you could immediately start spinning up a Drupal site and prototype something in that potentially even before or at the same time as designs and layouts are being discussed. My favourite thing about all this sort of thing is that I'm a really big advocate for involving everybody as early as possible in any sort of build. Everybody is going to come up with valuable information in the discovery phases. It's not one person's job to go and extract some information out of a client in order to make something work well. I think that's about the end of it, yeah. It didn't finish up so well, did it? I'd just make a note, work on finishing it better if you do it again. Any questions? Which sounds really odd, it works really well because everything kind of, then you have things to be laid out and you just didn't know how to do it. Yeah, absolutely. And if you have content, that's grand because then you start to design for content first, which is all of the content strategists and new actors who are so hot right now are totally advocating the content first approach. Yes, yeah. It's the age old thing, isn't it? There's been a design review and it's really good, don't worry about it. The designs were signed off immediately, I love it. And then you come and look at what's this new bit. Oh, that's just a little thing that I flourished in and they really liked it. It's been great. That's like an extra week of Dev. All right, pub time. Cheers.