 So welcome to what is UX and why is it essential to open source? And I'm Cassidy James. You may know me from the elementary team, but I'm actually going to talk about something that's a little more universal and applies more broadly to the open source community. However, I hope it does also give you some insight into how we do think at elementary when we're designing our product. So first a bit about me. I'm a co-founder of elementary as in elementary OS. I'm also a front-end web developer and UX designer at the Ubuntu Computer Manufacturer System 76. And I've studied UX informally for about the past 10 years and more formally for the past three. So let's talk about what is UX. We're going to cover what it is, why it's essential to open source, and how you can help ingrain it into your own products and projects. So first, how do we define UX? Let's look at some textbook definitions. This one's from Nielsen Norman Group, a popular UX and usability design firm. They say UX encompasses all aspects of the end user's interaction with the company, its services, and its products. Next let's take a look at Matthew McGain. He's the founder of uxmastery.com. He says UX is the what, the when, the where, the why, the how someone uses a product, and in addition, who that person actually is. In my words, I call UX why someone loves, hates, or is indifferent to your product. So it's important to remember that every product has a UX, has a user experience. If you go to a grocery store and the person who's checking you out is just super rude, that's a really poor user experience. So when we say we care about UX, what we're really saying is we care about providing a positive user's experience. So what is UX not? UX often gets lumped into these other categories, and it might contain a bit of these things, but it's really not all or nothing. First UX is not art. I like to define art as something that's created to evoke an emotion. For example, an artistic painting or photo is created to evoke an emotion in the viewer of that product. The composition, the subject, the lighting, they're all designed to make the viewer feel something. And a positive UX ideally does evoke a positive emotion in users, but that's not the whole of what UX is. It's not just art. A UX architect is not an artist. What they're doing is an art, and it may contain a bit of it, but that's not the whole. UX is not veneer. So veneer is a thin layer of wood or finish that's added on to the end of a product, and its primary purpose is for looks. It's sometimes to make the surface smooth instead of rough. But veneer can't solve critical design flaws. If you design a crappy chair and then you hand it off to a UX person to put the veneer on, there's only so much they can do. That chair might be fundamentally flawed when you sit in it, it breaks. And veneer isn't going to fix that problem. But too often products are designed in this way. They're designed and developed without a UX architect involved, and then that UX person is expected to fix all these problems by just slapping some pretty design on top. And this just doesn't work. Next, UX is not UI or user interface. UI is how an app or a product looks. It's the theme, the widget styles, the buttons, the text entries, the icons, everything you interact with. But UX starts much earlier than the UI. Going back to our textbook definition from Nielsen Norman, UX encompasses all aspects of the end user's interaction with the company, its services, and its products. So it's not just the user interface of the product, it's the entire over encompassing experience. A great example of this is a user that's trying to download a new app, a timer app. They might find one on the web or in an app store, and it looks gorgeous, and so they install it. And when they go to use it, they're really impressed with the UI of the app. It looks really pretty, has a certain sheen to it, it's nice and clean. But they realize it only counts up like a stopwatch. What they really wanted was something that would count down like an egg timer. The app looks great. Its UI is really good. But the user had a negative experience because it didn't solve the problem they were trying to solve. And the solution here isn't necessarily to just make the app do what that user expected. If it's designed to be a kick-ass stopwatch, it doesn't necessarily need to count down. The solution might be to make it more clear on the website or app store listing what it's actually designed to do. Ironically, by helping that user not download your app, you could actually be avoiding a negative user experience. Next, UX is not just usability or how easy something is to use. Usability absolutely is a part of UX, but it's not the whole. You can have something that's extremely straightforward and usable, but that is just ugly. My favorite example of this is Craigslist. It's very usable, it's well categorized, it has high contrast to the works, it's very usable. But the user experience is not always that great. If you list something and then your email inbox blows up with spam, that's a bad user experience. If you're looking to buy a couch and you're scrolling through and you find a couch but the layout of the page is kind of bland or ugly, that's also a bad user experience. It might be perfectly usable, but the user isn't having as good of an experience as they could be. And last, accessibility is, or UX is not accessibility. Accessibility is extremely important to UX and it is fairly well done in the open source world. And for the users who rely on these optimizations, like ease of use for impairments and low mobility, blindness, et cetera, the accessibility experience is definitely a huge part of their user experience, but it's again not the whole thing. So we've gone over textbook definitions and what UX is not, and that's ideally shed some light on what it is. But now let's take a look at what UX is and how it's approached in the real world in practice. First, let's take a look at the enterprise. Enterprise software specifically. UX in the enterprise is lagging significantly behind other areas. I recently had someone who develops enterprise software for a living tell me his enterprise clients were not looking for a strong UX, they just wanted it to work. That just tells me that those clients need to be educated what UX is. Another argument is that large companies can just pay billions of dollars to train every single employee that'll ever have to use their crappy software and that that's a good replacement for UX. Maybe they don't phrase it exactly like that, but that sort of mentality is prevalent. They think that training can supplant a good UX and it's really, really costing them. The Association for Talent Development recently did a study of over 340 diverse organizations of various sizes and found that on average, a company spends over $1,200 per employee on training. Now, that might not sound a lot for one employee, but if you took that $1,200 and multiplied it by the number of employees a company has and then spent that money on UX instead, you would end up with a much better product. Plus you'd have even lower training costs because you wouldn't have to replace people who quit due to the crappy software. Similarly, the IEEE found that 5% to 15% of enterprise projects are scrapped due to poor user experience. That's a huge wasted chunk of resources. That's 5% to 15% of all the work that you're doing. And basically it shows that UX and the enterprise is just seriously behind and it's costing companies a lot of money. Now let's take a look at kind of the other end of the spectrum, which is startup companies. Wildly successful startup companies think UX first. They care about the whole experience a user has from first hearing about a product to using it every day and then on through how that company will monetize it. Now this is particularly important to startups because their first goal is to gain adoption and fast. A critical point in a startup's life is how they monetize so that they can keep building cool stuff that the users like, but without sacrificing the UX that got those users there in the first place. A successful startup will have built their business strategy into that user experience. If you just tack monetization on after the fact, it's going to kill the user experience or they're going to have to completely redesign, which as we saw on the enterprise side, that that costs a lot of money. And the business strategy and how that affects the users is a large part of the startups UX. Just as large is a user's experience interacting with the brand itself outside of the product, whether that's via social media, email, a support system, or even advertising. If a user loves a product but gets ignored or blown off by a support team, that's a net negative user experience, even if they like the product itself. If the company comes out with a distasteful or offensive advertisement, that's also a negative experience for the user. But if a user gets super fast and actually helpful response on social media or via email, that's hugely positive UX. And that affects how the person perceives the product as a whole. Next, let's take a look at a field probably most familiar to us here at a Linux Expo, which is open source. Contrary to what Brian Lunduk may tell you, open source is awesome. Anyone can take existing code, solve their own problem, and then give that back to the world, which is incredible. However, this can create a lot of UX problems. If an open source project is designed to scratch a particular person's itch, especially say, a fairly technical user who understands open source and programming, that solution might not provide the best experience for other people, especially less technical people. And to counter this, often open source developers decide that they should let their users set up the tool for how it should best serve them. But the problem here is that the developer is just passing on the design process to the end user. It's forcing the user to make decisions that a designer should have worked out ahead of time. In addition, this is creating exponentially more complex testing processes, because you're increasing the combinations of configurations that can coexist, which just is a mess. And lastly, too often in open source, developers are building without a UX architect. So I'm gonna tell you a story about an architect. My wife and I are Airbnb hosts, in addition to our day jobs. So if you don't know what Airbnb is, it means we invite strangers into our home for exchange, for some money, and the promise that they won't murder us in our sleep. I recently had an awesome guest named Xander, who was an architect. He specialized in restoring or remodeling historical homes, keeping in mind the original designs and styles, but making them more livable for modern families. Now, the way he first explained it, I thought he was an interior designer. I thought he was brought in after a renovation was done to kind of decorate in the style of the original architecture. But he quickly corrected me. He was an architect. He was involved before the renovation ever began, and he played a key role in actually planning it out. He studied architecture styles from various eras, and had some artistic ability, but his expertise was in listening to the clients and listening to their needs of the family, figuring out how to create a space that both served them, but also stayed true to that original style of building. Now, he wasn't a construction worker. He wasn't the one actually out there putting up the two by fours or laying flooring, and he wasn't an engineer. It wasn't his job to know exactly what technical specifications every material had or the finite details of how it would be built. However, he did deeply understand those people, and he did work with people in those roles, which is part of what made him a great architect. In case you haven't figured it out, Xander is to historical renovations as UX designers are to products. A UX designer is not just a visual designer. Their job isn't to be brought in after the thing is built to make it look pretty. They should play a key role in actually planning the product. They should have studied various interfaces and techniques, and yes, likely have some artistic ability, but their expertise is in listening to the needs of the users and figuring out how to create a product that serves them and the product stakeholders. Now, they're not a developer who is actually creating the product. They're not the engineer making technology decisions, but they do deeply understand and work alongside those people. Now, imagine if someone in Xander's role didn't exist during one of those renovations. The family could draw up what they think they would like, but they don't really have the technical knowledge or expertise to know if it's gonna work out, or even if it'll fit into the historical style of their home. The construction workers would have to try to filter out the families asking them and telling them to do, which will probably change along the way while they're building the thing, and they have to try to turn that into a finished product. The engineer might be able to identify the right type of material to use, and he might be able to ensure the final renovation is up to code, but without the architect and the blueprints, they're flying blind and making it up as they go. If they're lucky, they might end up with a livable space, but it would end up being something that was not well-designed, and most likely they would end up redoing work they'd already done that could have been avoided if they had an architect like Xander guiding them. So this is a problem that we face in software projects, open source or not, every day. Insanely talented people with exceptional technical knowledge and ability are working together, and we build workable products, but too often there isn't an architect that's there drawing the blueprints up before the development begins and guiding the process as it is happening. This means we don't pay enough attention to things like platform guidelines and conventions, we don't listen to, study, and work to understand the users, and we end up spending a lot of time redoing things. This is why we need UX architects. That's why I like to use the term UX architect instead of designer. On that note, let's take a look at what UX should be. UX should be the why. It's not just the what or the surface, but it's the reasoning behind the UI. Like an architect who designs buildings with a world of knowledge of that architecture type, technical limitations, and the client's use in mind, a UX architect must think through how and why the user will use that product. And next, UX should be the strategy. A positive user experience goes all the way back to the goals and the stake, the goals of the product and the stakeholders, whether that's a ragtag group of friends on the internet like a lot of open source projects or a large corporate funder. It's nearly impossible to create a positive user experience if the core goals of the product don't include key elements such as simplicity, usability, and desire or delight. Next, UX should be pervasive. Those core goals of simplicity, usability, and desire should permeate a project. Everyone involved, whether it's the UX architect, the developer, the engineer, a marketer, or even a social media person, they must always be thinking of the user. That effort to create a positive user experience must be involved at every step. So to finally get back to the subtitle of this talk, why is UX essential to open source? Let's be honest, a huge reason is that it helps us compete with closed source software. Developing a positive user experience doesn't always cost a lot of money. In fact, as we saw earlier, it can help us save money in the long run. And oftentimes, open source projects are severely underfunded. And this is one way we can help combat that. In addition, open source development is more agile. If ideas are developed in the open, we can more quickly react to the changing landscape. And by keeping those UX findings and developments in the open, we can compete with closed source software by trading ideas to and from other community projects, other open source projects. You can actually see this in action in the Linux desktop world right now. Not only are projects like GNOME, KDE, and elementary learning from what closed source projects are doing, we're actively learning and improving on ideas from each other. Next, UX helps us be accessible to all. A focused user experience can help lower the barrier to entry, especially for less tech-savvy users. This lets us create a cleaner user interface, which means simpler documentation, which means fewer translations, for example. And all of this helps get the product out of the way, even for more advanced users. A more streamlined product means less time fiddling with the product and more time actually getting things done. Similarly, UX is essential to open source because it can vastly improve your code base. That focused user experience means there's actually less UI to develop, which in turn means there's less code to maintain. And we actually see this all the time in elementary. A lot of times we look to find ways we can get rid of code by making the UX better, by streamlining the UX. And this also means there's less to break along the way. Fewer combinations of configurations mean fewer variables to test against, which in turn help you develop more code faster and better code faster. And lastly, this helps you implement the actual, actually spend time implementing the features that you want and that you care about rather than just working on maintaining existing code. So we've answered, what is UX? We covered the textbook definitions, my definition, what it's not, how it looks in practice, why we should call UX people architects, remember Xander, what UX should be and why it's essential to open source. And we could stop here, but I feel like there's one more essential piece to the puzzle specifically for open source. And that's how to ingrain UX into your open source project. The most effective way is to ensure that there are UX architects at the leadership level of the project. Their job is to ensure that the focus on the positive user experience is pervasive. With the UX architect as a major stakeholder in a project, you'll have jumped one of the biggest hurdles in creating a positive UX, which is getting the stakeholders on board. And this is something we've seen a lot of, a lot of success with both inside and outside of open source. In open source, you have major projects like elementary OS and Nome who have designers very high up and within the projects, ensuring that the team is constantly thinking about the users and their experience. Then you have companies like Google who recently did a 180 by elevating the designers within the organization and developing a whole new design language with a huge focus on a positive user experience. And Apple, I believe, they're still the most profitable company in the world right now. They have designers at the very, very top who help shape the entire product line and user experience. This is how you ingrain UX into a project. You ensure that they're UX architects at the leadership level. You can also hire on a UX firm or UX architects as early as possible. Remember Zander, the architect. You need someone there who is looking at the process from the beginning and helping design the whole experience. And paying that person, if you can afford it in an open source project, is just as important as paying a developer if you can afford that. They'll play a huge role in determining the success or failure of your product. Here's another easy one. Treat UX issues as critical bugs. A poor user experience is just as critical as a segfault in your application. Both leave a nasty taste in the user's mouth and they make it more likely that they'll go look for some other alternative. Daniel Foray, the lead UX designer of elementary, likes to say that if a feature is too hard to use, then the feature is broken or doesn't exist at all to the user. So you need to treat these UX bugs as critical issues, but they also need thorough solutions, not just ugly hacks or workarounds. Never fix a UX bug through documentation or a message telling the user how to do it the right way. Ideally, make it so that the user can't accidentally do it the wrong way. Next, a very effective way to ingrain UX into an open source project is by always thinking UX first. Start with the user's experience and then work backwards to the technical solution. Don't start by trying some new technology and then trying to figure out a reason to use that technology. That's like creating a solution and then trying to come up with a problem. And really, this one's a common theme, a central tenet of all the previous points. Always be thinking UX first, not technology first. Lastly and similarly to the previous point, remember to continue to perform UX tasks as your product evolves. It's not just a one-time consideration to do at the beginning. You must always be designing. If you're implementing a new feature, test that feature. Always get user feedback. It's incredibly valuable. And users won't always have the right solutions. Oftentimes, they'll tell you how they think it should be designed. But your task as a UX person is to figure out why they should think, why they think it should be designed that way and to design a solution that will work for most users. So to recap, what is UX? I like to say it's why someone loves, hates, or is indifferent to your product. And why is it essential to open source? It helps us compete with closed source software. It helps us be accessible to all and it can really help improve your code base. And lastly, how do you ingrain into an open source project? By getting UX people in leadership, hiring UX people early, treating UX issues as critical bugs, thinking UX first and continuing to perform UX tasks throughout the lifetime of your product. Thank you. So I don't have a real formatted question and answer, but if anybody has any questions or thoughts I wanna share, we have a few minutes to go over that. Yeah, so I have both formal and informal training in UX and how do I differentiate between the two? I would say the informal training is just Googling it, teaching myself a lot. I mean how a lot of the developers start developing, I believe. I found that niche and was really interested in that. The more formal training is actually, I studied human computer interaction and computer science in college and then I actually worked for a UX design firm as well and now my current position is a front end web developer and UX designer at System 76. So more formally and more official role and also studying it in school. Right, yeah, they don't have certifications. Some, a lot more universities and colleges offer programs specializing in that. It's weird, sometimes you'll find it under the avionics or aviation courses because that's kind of the origin of UX was designing airplane interfaces. So sometimes they'll have weird certifications related to aviation that actually are UX or human computer interaction. I'm sorry, I'm trying to understand. Yeah, right, so ideally, yeah, so a company will have requirements of what they think the product should accomplish for the company, but it's really important to distinguish between what the company wants to accomplish for themselves and the requirements of how a user, what it accomplishes for the user themselves. So they are related and they should take those into account for a UX designer, but a UX designer's role is really to figure out the user's side of you. So it's how that makes the user feel what the user can accomplish with the product itself. Yes, in the back, like a more specific example. Yeah, I'm trying to think of something specific. So one example, this is actually for System76 working on the new website that we designed about a year ago. We started, we wanted to make it really easy to configure a very complex laptop or desktop system on a cell phone. So our whole entire website is UX first, or is mobile first, and scales up to the appropriate sizes on a desktop. So instead of just kind of using the existing system that was there and then testing what we thought would be good and just going with that and if sales were down, we'd improve it, which is kind of the workflow a lot of companies have. We actually took a lot of time, stepped aside and drew paper prototypes of how we felt the user should step through the process. So we figured out, okay, what are the most important things the users cared about, and it's the processor, the RAM, the different pieces of the computer. Separated those out into different groups and figured out how a user would kind of work through that process. And we took those paper prototypes and we tested them both inside and outside of the company. So I had different people come over and say, imagine this is on your phone, it's a piece of paper, imagine it's on your phone, how would you step through this? And that was actually really effective. We solved some problems like on a desktop we felt that scrolling a lot was a pretty standard thing that we expected to do on the web. But people expected to be able to swipe left or right on the mobile device. And so that affected our design input before the product was built. And we've made tweaks as we go then. As we see users are running into a specific problem like they weren't sure how many steps there were in the configuration process. So we added some little dots at the bottom of the page that show how many steps there are. So that's kind of examples of both always improving the product, always reviewing it and always also just starting with the user experience, not necessarily starting with the technology. We ended up using some JavaScript library that handled the touch events. But we didn't start with that JavaScript library and say, all right, how do we make this work for our product? We said, we'll start with the UX and figure out what JavaScript library we need. Any other questions? All right, well, thank you all for coming.