 Can we disconnect? Just in case. Yeah, no problem. Can I not mess this up? I don't know. Could you export this? There's a pin here or something like that? Yeah, I don't know. I don't know if maybe there is a problem on the website. I don't know. No problem. Take your time. I don't know if you want to see. Security first. He's a little lost. Perfect. The magician. I'm not sure what it is. I think I don't have enough time in three minutes to figure it out. Sure. Just to be sure, your name is Roman. Roman. Just don't want to pronounce it. No, it's not. Roman. Usually in English I always say Roman likes Romans. And people are making fun of me. Oh, Simon likes the Simon. I don't know the title of this, but... I mean, can I set the joke a little bit? Just the fact that... Oh, crazy. I mean, crazy. Yeah, like, there's a lot of people that are older. But I mean, it's weird, but... Yeah. It's cool. It's cool. It's... It's hard, but not... It depends on you. Yeah, I guess it's the first one. Yeah. Yeah. Because then they will still come in. They'll make a door, so maybe you want to wait. Yeah. And it depends on you. Yeah, I guess... Maybe just wait for it. Okay. It's too little to, I guess, make any difference, but... No, it should be fine. Yeah. And you are working for an app? Yeah, so from the authentication page in the U.S. In Brisbane. In Brisbane? Actually, I have a colleague in Brisbane. Right here. Fraser? Yeah, awesome. His IDM and... Especially, I guess, mostly in certificate servers. So, do you also work on the free IPA? Yeah. I work here in Berlin. Most of our team is here. I saw Fraser, right? Last year? You were here last year, right? Yeah, I was. He's my high school mentor. He teaches... Well, not teaches, really, but he's helping us doing functional programming and stuff like that. He's a bit of an advocate with that. I kind of always wanted to learn about it, so... I know he has a few bad projects in the high school. Yeah, it's fun stuff. Very abstract, though. Yeah, I like the abstract part, but when it comes to monads, the output input, I hate it. It's so awful. The function part, the pure function part is nice and... Mathematics, in other words, but the monad of modern life. At all. Is there a technical aspect you don't like about them, or is it just the theory? I think the theory. It's just... break the whole nice idea of pure functions. But it's not usable without it. I know it. There was this interesting video from Simon Beacon Jones about the difference between useful and theoretically correct, where he says, well, you want something with side effects on us. We can't do any computations. I understand. I know it's useful. I need it there, but I don't like it. I mean, what I stumble over most often when learning Haskell is what I like about it is it's challenging. When you... I was working with Python and basically procedural and object-oriented program for years, I'm still doing it. So Haskell's challenges. But any fact you touch on programs which I guess challenges this. You can think about something in new ways, but the amount of... I was at the last freshman when Matt was there and he was talking about cool walk-in up and down like a tiger and doing all this theory and I was just sitting there. This is my first conference where no clue about what people are talking about. Yeah. So that's... I think that's also what lots of people feel like. Half an hour thinking and three lines of quoting. It magically works. So that's kind of a cool thing, what I have to say. And also that everything is so really compact so you don't find functions which are lots of time. It's almost impossible to... Yeah. Maybe let's start. I don't know. I will start with some general announcements then. Good morning everybody. Welcome to the second day of DeafConf. I hope you enjoyed yesterday's presentations. Just a few reminders. Today in the deep building there is a whiteboard. You can vote for lightning talks for today's evening. Another important thing after lunch, sometime after lunch, it's not ready yet. There will be spare tickets for party this evening. I believe it was 3 p.m. 3 p.m. is it set? Okay, perfect. Thank you for the information. And it's probably all. So our first presentation today is about user experience and developing for user at the first. Please welcome Romain. This morning I felt like 9 o'clock in the morning. Probably everyone had a tough night. Thanks for joining this. I was thinking I structured the talk around my own experiences especially I first want to define what my problem is in terms of application development. Especially focusing on the user. And then I want to introduce personas, what they are and how we create them, how the theory around creating them is defined and what our experience so far is using them and creating them. Maybe just quickly about me I'm working for Red Hat and Brisbane. I'm a software engineer and sort of part-time product manager for Beaker and for other people who have never heard about Beaker. Beaker is being used at Red Hat for hardware integration testing and Beaker itself can manage a whole lab of test computers. I also have a few confessions to make. I'm not a user or usability engineer. I'm not an interaction architect. I'm just a software engineer and this persona design process is something that I found out about and I when I found out about it I thought it's a really interesting concept and basically this talk is about our first experiences applying and using it and that's where I want to already come to the problems I've encountered in my past experiences for application development in terms of centering around the user. I can only speculate but I think we sort of in open source we start off with a problem and we start off with a solution which sort of targets exactly this problem and from there we sort of grow and we create a project and there are more people contributing to the project and so we see more contributors, more people involved and the more it grows the harder it gets communicating between each other especially communicating sort of a prime vision of what the software should do and what the actual user is the bigger it is the more it is obviously also prone for people who might just use the software for not its intended purpose they might define its vision as well so this growing software thing has its problems on its own the other thing is if we look at user-centered design I think I've never met a software engineer who said I will fully make this UI really shit so people can't use it I think all people I've met so far they are really interested in making UIs really usable but when you look in the usability space you find things like never forget the user don't make it feel stupid but the thing is what does it actually mean how can you actually achieve that and in my past experience we tried to alleviate that we tried certain solutions to employ in order to focus more on the user and I want to present three of them which we've used so far and all of them I felt were kind of helping but not really targeted so the first thing was something I stumbled over from Joe Spolsky and he was mentioning hallway usability testing and I thought that's an awesome idea you just grab someone off the hallway put them in front of your application and give them a scenario a set of tasks and you observe how they stumble through your application and derived from these problems he has you tweak the UI but as it turns out depending on what software you're actually implementing if you have intermediate or if you target intermediate users or expert users the guy you're picking off the hallway might not represent the expert on the intermediate user and so what his state is reflecting is probably not reflecting what your actual intermediate users having problems with your UI and the other thing is you usually test on an already fairly complete artifact and that is almost too late in the design process you want to have something or you want to have the feedback much earlier so usually testing might not be the nice the right thing so let's ask the users because they should know they have the problems and we do that too and the problems we stumble about here is that for Biko especially users are usually software engineers and as we all use software we use Google and we use GitHub and they seem to be employing nice usability and nice user experience they seem to get it right so if we ask users they usually come up with solutions and asking more and more sometimes is a really frustrating process for the user and for us and that can sometimes take ages so for me as a product owner who joined the Biko project just a few months ago asking all users about the problems could be a really frustrating thing and could probably take years so that's that's not a real application here as well and I think the worst thing which comes out of that is that you sometimes end up with contradicting bug reports so I've got an example here the red hat bugzilla sorry just change the component list and in bugzilla if you follow a bug report for a product you have to choose a component there could be documentation the scheduler part of the product whatever and for the typical products that component list is perhaps 5, 10 items long so not really big but fedora also uses bugzilla or the red hat bugzilla to track the bugs and that component list is 100 items long and so when the engineers tried to change this component list to be more performant and more usable from a simple select box to something more javascripty something more nifty that bug tracks tons of users who say ah remove it that's awful other people say advocate hey let's move even further into the jQuery or javascript approach because it helps us so much and that is because some people need to pick a component they already know exists there and some people actually need to browse for components so there are these opposing goals people have when they are filing a bug and just asking users here isn't a solution and the last thing I've encountered actually also applied in various projects before doing good UI elements as I said we all like using Google and whatever nice UI we're stumbling up on and we find these nifty widgets which help getting our stuff done so we think hey let's borrow that put it in our UI and we should have no problem helping our users the problem is consistency so I have an example here which is a GitHub issue and as you can see you can comment and on the issue you can comment and close the issue for GitLab which is sort of the open source portal to GitHub they've implemented a similar thing but if you comment and click on close it discards the comment on the issue and people are sort of leaving a dumbfounded where's my comment I think they fixed it now but if you are not paying attention to the detail you basically end up with an inconsistent UI and I think what all these problems have sort of in common is that we sometimes I think as software engineers we mistake making things pretty with making things functional Don Norman in his book Emotional Design he made studies on cognitive emotional processing of humans and he found three types of how we process information there's visceral behavior and reflection and then Alan Cooper in his book about personas he met these three types to different types of goals that we actually have in our life and how we use UIs and the first one, the visceral that is all about making things pretty and that corresponds to experience goals how the user wants to feel about using a typical UI then there are the typical end goals which map to behavior and what the user wants to do and I think that is something we developers can actually nail without making things pretty and the third part which is less common or less important but also should be mentioned is the reflection part which corresponds to live goals so something who the user wants to be and I guess all of us have seen really good products and really good products address all three types of things so if you I almost hate saying that but if you use an Apple iPod or something you know it's really nifty it can be used really nice and they always sort of convey this this nice life life thing that you know your hip if you're using it so they address basically those three things and so having said all that about the problems with the what we've encountered so far I basically want a tool which improves communication our team is not only in Brisbane our team is in China in the US so around the globe and if we want to have a common focus on the user we need something which improves communication and the other thing is when we talk about user goals I also want something which cannot only be applied to graphical user interfaces so user interfaces can come in many different types and forms and we have terminal applications console applications and striving to address user goals should be the same thing as graphical user applications and that's where personas basically come in so what are personas the first time I've read about personas is in Alan Cooper's book the inmates are running the asylum and the book is sort of split up in two parts the first part is a huge rant about how shitty we suffer engineers get the UI wrong but if you get through that the next part is where he explains how he uses and utilizes personas in his design process and it's a really enlightening story the tricky thing though is it's really high level and he doesn't convey any kind of process but from then on I heard about personas and I thought I want to use them and that brings us basically to how to create personas and if you look around on the internet you find all kinds of personas and the tricky part is that most of them are employed by web designers for web pages because it's an application it is a web application but it is still an application and when I try to copy what is being found on the internet it's really tricky because they use and employ a lot of fictional detail which because you're creating a design tool which doesn't really help in the design tool if you just copy and paste the stuff or rather not copy and paste it but try to come up with your own fictional details so be careful about that Koopa itself created another book and it's called about face and in about face it provides about eight steps on how you get from the raw data the information you have into and put that into knowledge into personas and the next slides I've split it up a little bit into first the theory and then I talk about our experiences on how we created personas and what problems we encounter so the first thing we did was preparing and you want to prepare like ideally you want to look at how you can segmentate your market and that can be like for a red head it's sort of easy because you can just pick user roles and different people working in different departments if you're not, if you're working outside then perhaps market segmentation would be a first step to go and split up your users then interviews you do user interviews and record the sessions and especially important is that you use open-ended questions let them talk about a scenario and let them talk freely don't intervene and the third step is that you identify behavioral variables what they are I'll just explain in a moment and you create a map and map them so for the first step what we did as I already said we just picked user roles inside red head because that's something we're aware of and it's really an easy way to go to one hint try to find as many people as possible who want to do an interview ideally what you want to do if you have people on site go to them and observe them in their real environment I almost said in the wild basically because the thing is you also want to see if they are getting interrupted do they have any problems that is obviously something if you just do an interview for an hour you won't be able to see you can ask for it but that's a tricky thing but for us it's the best tool we have what we then did we used a tool called blue jeans it's similar to Hangouts and the cool thing is that you can record the session and that's very important because you might have arranged a set of users to interview and you don't have the time to write everything down because you want to focus on the guy you don't have any plan in terms of how exactly the interview will pan out because you want to be flexible and pay attention to what your user is doing and also target the questions to what your user is doing because all you want to figure out is what is his motivation what is his end goal in terms of what's he trying to achieve there what we then did we send out invitations personally and to mailing lists state what the procedure is and I've also stated or made clear that the session is recorded be aware that if you say that the session will be recorded you should also mention that it's just kept privately because that puts a lot of people off if they know they are being recorded the interview itself as I already mentioned avoid any fixed set of questions and that is something the next point is something we've stumbled upon really often don't discuss technology for us software engineers it's really really hard to stay out of it especially if you have or observe users and they have problems you feel like you want to help them and you want to try why is that why are you having problems here so the best thing is we have a lot of tutorials and let them explain what their typical pain points are what they usually do on the next slide I have three typical questions who target exactly the motivation and goal level and especially the last one the shortcuts is something users employ heavily for beaker which makes their life easier and that's something we want to target and figure out why they are doing that so after the interviews for us it was really interesting to figure out why people employ certain workarounds and what we also gave out is a small reward so if people already spent their time with you then it's good to give something back finding behavioural variables was a really tricky thing for us so Cooper defines behavioural variables as activities, attitudes, aptitudes skills and motivations the first thing you will find is activities because they map to frequency how often do people things and what we started off was it's using post-its it's sort of really handy you can rearrange them you don't have anything digital and it helped us to discuss and brainstorm about what possible things they are people are doing use your recordings obviously you want to derive that from your recording the next step what I've done was we digitalized it using Inkscape the vector program is really easy to do quick changes and use fonts and whatever they are also pitfalls with the mapping because the first thing we did and the first go-to item or variable we went with is activities and we had tons of activities people are running jobs finding things how often they do that etc we also used user roles instead of our users we do want to use and map your users because user roles don't tell you anything some users do certain activities more often than others and you want to find clusters in the next step I'm just coming about too so don't use user roles or any of your market segmentation map your users the other thing is we ended up with lots of activities here and map them on the frequency that is also not telling much about motivations and what people are trying to achieve so we had to go back and basically now we ended up with still with activities obviously but with more skills and aptitudes so as an example we ended up with requires access to bare metal as an attitude and drives process automation as an as an aptitude we still miss on skills and that is partially because we started off with an incomplete set of questions so next next steps are theory again defined by Cooper and and once you have that map you want to find clusterings clusterings on behavior so if you have that map you basically if you find certain logical clusterings then that is most likely a goal people trying to achieve and as an example so people who buy CDs are most likely also trying to download mp3s so that is a typical clustering which is logically consistent once you have the clustering on the map you can infer the goals and that is where you start creating your personas each persona maps around one or two goals and you start off with depending on how many users you interviewed ending up with four or five, six personas and use bullet points to map out the goals you inferred so once you have a set of personas you want to figure out which is the primary persona which is the guy, the hypothetical user you want to design for and you nominate one primary persona if you feel like you either made a mistake or it could mean that you really have more than one primary persona and that usually means you want to design an interface for each primary persona and from then on it's basically a final step what you can now do is you have the set of bullet points for your personas give them a name, give them a photo they should feel like real people even though they are not they are just composite user types and you can also write out of your bullet points, transform it into a scenario and a story be aware though that don't put any fictional detail in which is not really helpful for your application and your persona so in our first personas we ended up with education and hobbies and stuff like that but you know how does it tell that we specialists like cooking exotic meals in terms of running jobs so there was something absolutely of this world so for us in our experience when we looked for patterns with the set of users we had or interviewed so far it was sort of clear I'm worried that we are not sort of following a bias here but we just run with it and inspect and adapt and see how we go when we inferred the goals from the map we started off with a simple set of motivations and mapped them out into bullet points that allowed us to discuss it with other team members still and not sort of set anything in stone so what I have here is the first persona don't worry if you can't read anything but the first the first personas we've identified they still have a lot of fictional detail as a sad one I had hobbies and personality and stuff like that I did have goals and I had key differentiators but what put me off here was that none of this was created based on user research or any type of process this was created based on the interviews and as you can see in the next example the persona we've actually ended up now with is in different in many ways due to the fact that the scenario depicts his current pain points so I started off with writing a scenario of how it should look or how the user interface should behave and you want to start off with the persona with its current state of of using your software due to the fact that I've changed so I haven't added a I haven't added a photo yet basically the new persona we've derived from our interviews is basically a QE engineer and he only has one goal and that is prevent regressions in the software and a test there's another one we found he's trying to find regressions in the software we have frustrations and pain points and as you can see they're all bullet points it is something really nice for engineers who are sort of a bit flaky on writing narrative and scenarios for them it's much easier to write bullet points and just flash it out quickly and in terms of a communication tool if you want to talk about it just reading a few bullet points is much easier than writing a whole scenario in terms to use to using personas as I mentioned the primary form of a persona is a communication tool Cooper defines using personas by writing scenarios and he defines it as writing very broad scenarios and then define more and more detail or add more and more detail into the scenarios for the software you're designing whoever was at the pattern fly talk yesterday they employed personas in their design process in the beginning I don't know how they use it if they just use it as a reference and see if they're not violating any end goals when they're designing new interfaces but Cooper is a bit wake in terms of how you validate that you are finding the right sweet spot when you employ the personas I think that's something we just have to find out for Biko itself Biko uses a design process which is centered around design proposals and we use some kind of pep proposal people who use Python they might know that Python uses the peps to set out motivation and why you want to change something and the good thing is that it puts people into this state of mind of what can happen, what you want to change so for us we want to incorporate the personas and drive the design documents based off the personas we haven't done that yet I'm sorry I can't give you the experience due to the fact that we haven't had the time to employ them yet obviously that is a really elaborate process in how you get to personas so why should you actually create them personas in itself from the user interface sort of reminded me about creating automated testing and as you can imagine if you have never written any tests it's really hard to ramping up on automated tests and writing integration tests so if you don't have any personas start creating them is an elaborate task but once you have them in place it can help a lot in terms of clarifying and communicating around the users and avoiding making mistakes which violates the typical tasks people perform with their software due to the fact that creating personas can be stretched and can be a side thing you do while you're developing your application if there's no time you still end up with a hypothetical aspect of what your user should be so there's the benefit of having a focused communication around your users there are also closing questions well it's still something new to us we still need to find out how it works for us how we can sort of scrap maybe aspects of the process which is not so important for Pico itself and for development so we're still learning if you have experience with that please come to me I'd be really interested in talking to you any references I can highly recommend about Facebook from Alan Cooper if you want to dive into it there's also a smashing magazine article a closer look at personas where he follows the Cooper idea of creating them I can recommend that as I said be wary of any other websites who put fictional detail in the design tool which can be really confusing and not helpful at all and that's the end of my talk thank you very much for listening any questions welcome so thank you Roman that was very insightful helpful question regarding like just usability in general so maybe you can give some insight so a lot of development teams have significant backlogs and a lot of that backlog is made up of bugs or significant future requests and often times usability enhancements or changes take the back burner we never make it in all the other priority items in the backlog do you have any suggestions or recommendations on how you guys would generally address that so basically how we can prioritize on a set of usability issues what are the most important ones I think knowing the end goals of what the user wants to achieve with your software should help you prioritize the list of usability so it might be that something is in the bug list of making things pretty but it might not really address the end goal of the user so if that's the case maybe prioritizing more on the functionality part would help the user more than having it pretty so I would go for that June so June was asking about when you do the interviews don't set off with a fixed set of questions and I agreed I didn't mean just walk in with the blank slate and just see how it goes you obviously want to have sort of broad questions which address a broad area and then you drill down but this how you find out and observe that should be up to you and you should be able to drive that anything else I waited generally to figure out the source project people are using it I need anything else that could happen and work for me it's a fundamental function for me but I'm a different person I can break their use cases for my own that's a typical thing with how you create process improvements I see that as a process improvement and that can be a really hard thing to employ because you need everyone on board and use it to make a testing because in the first years people are like why do I need to test it just works, you can see it so getting people on board is a really hard thing and if you have any other questions please talk to me I'd be interested yes, you want to design only for this one I would guess the primary number of users of the software general doesn't have to be people make the mistake that they say we should pick the biggest market segment because that's the users we're targeting for I can't speak for myself but Alan Cooper has this prime example that for example the flight attendants have this trolley they pull themselves and they made this trolley for the market segment of flight attendants but they were so awesome and so became so popular that everyone wanted to have them so his advice was basically don't designate the broad market segment and use one persona even if it's just 20% but make him happy and make him love your software because anyone else who comes then wants to use that software too please if you have any further questions reach to Roman and ask him he's on the run right now thank you for your presentation please provide a feedback export it as a pdf and upload it to the flight you can do it later and bring it back if you want we have a special sticker for our speakers I can put it on my laptop if you want thank you it was really interesting I think it's probably not solvable at the time because