HOW TO BUILD THINGS THAT MATTER

Speaker 1: So thanks for coming. I uh I had a little studio in the back of my Um house where I do most of my work and so I don't ever see this many people at one time ever. So we're a little bit nervous Um I wanted to before I get started, if there's any back channel conversation about uh what I'm gonna say, just go ahead and tag it with MATAHK, and then I'll be able to kind of follow up and um participate. So about me, I'm an entrepreneur and a designer and a hacker. I was classically trained as an artist in New York. Um so I made the transition from painting and oils to coating was kind of a fun little trip, but the thing that I found really useful about that was

Speaker 1: It's easy to get beat up in art school uh because people just rip your stuff up and then to go to try to work with a client when they don't understand what you're doing or you haven't communicated well and they can rip you a new one and it's not that much of a big deal Right now I run a small company with my business partner named Pierre Blue, and we primarily focus on behavior design and healthcare. And I'm happy to talk more about that another time. So the first thing as a speaker I want to say thank you to all of you guys, not only for being here, but I spent a lot of time on IRC over the past 10 years. And you guys have helped me out at 2 o'clock in the morning when I'm trying to figure out a problem. And literally if it wasn't for you guys, I would not be able to feed my family.

Speaker 1: And I would not have to I would not have the opportunity to pursue the the passions that I have. Thank you very much, and I'm hoping that this is a little bit of a give back for you guys. So how many of you guys are building your own web apps for yourself or for your own startup? Okay, great. And then how many of you are building web apps for other people, clients, that kind of stuff? Okay, a little of both. Good. Okay, cool. The things I want to talk about today are not necessarily about building another social network or another analytics tool or another way of connecting Twitter and my whatever music I'm listening to. And if you're working on those things, I apologize if I if I've offended you, but I I want to talk about finding real-world problems and trying to provide solutions to them

Speaker 1: And I think that there's a couple really key things about the stuff that we need to work on and how to help those problems be solved. As an example, obesity in the United States is a huge problem, both financially and from how it affects the people that we know and love. It's a big contributor to diabetes, heart disease, stroke, and cancer. A five-minute Google search will show you all kinds of uh stuff to get you uh excited about helping find solutions for obesity. It's a hundred and ninety billion dollar a year problem. And this is just in paid medical costs. This isn't even around lost productivity or anything else.

Speaker 1: This is just what we pay in the United States around medical care, around the problem of obesity. It's a $14 billion problem in children alone. It's a significant deal. And one of the things that can really help in dealing with obesity is simply going for a walk. Pinning up and moving around. A lot of the literature that we'll see will be exercise. And I made the argument recently that exercise is something really hard to get users to do. Because if you do a Google search right now for exercise, you're not going to see anything in there that looks even remotely like what you look like, unless you're like one of the one or two percent of us who are really in shape So and I don't mean us, I'm not just

Speaker 1: poor. But the the kind of the stigma around what exercise is and how it works is a really, really challenging thing to overcome Especially when you consider things like gym advertisements as you drive around your town and and you look up at the billboards. I don't know anybody that looks like that. I would like to, but I don't. And I think the idea of walking or just simple movement is something that could have a huge impact and could really help fight the problem of obesity in the United States. Of course we can look at high sugar drinks and all that other stuff. But the reality is that going for a walk has other implications as well. It helps offset depression. It was found that in 47 % of folks who uh deal with depression, going

Speaker 1: for a walk helped to decrease their reported depression score. So moving around and having some sort of movement is something that could be done and would help a lot of people. And I think that in this room, we're uniquely qualified to provide tools that would help people be excited about getting up and moving around. I think that there's some pretty awesome things that we could be doing as far as gaming is concerned. Just basic email using the I mean who's sort of Django Drip, the Drip library? So using that as a as a tool, you can create an email drip campaign on whatever app you're using that will remind users that they want to come back to the application and use it so that they can continue to get up and move around.

Speaker 1: There's all kinds of stuff that we could be doing. There's a lot of problems that need our help, our unique skill sets to be able to help them, mental health, poverty, education, social justice, the environment, wounded warriors, and many, many, many more. These problems are all in the domain of uh being able to change behavior. So if you can create an application like a game that changes people's behavior, perhaps you can do it in a way that would benefit them or benefit society. My business partner and I have a little passion project that we're working on. for uh fly fishing and it's really just a simple fly fishing diary. You know, we live here in the Northwest. I'm way more comfortable on a drift boat on the Mackenzie than I am standing up here on the stage

Speaker 1: And we built this app so that we could start to look at ways to collect data and make those data points more accessible for other folks so that they can understand how the fishery health is, the river systems that are all around us. So building things that matter, building things that can actually change lives or have a real positive impact are something that I feel like we're uniquely qualified to do. The problem is If no one uses it, it's not a solution. If you build an application and no one uses your app, then you haven't really solved anything If you build an application and you get that first thousand people in and registered and then you have fall-off after, say, two weeks, three weeks, how do you know that you're actually affecting behavior?

Speaker 1: And so if we agree that there's things that we could be doing to really help people change people's lives, then what we need to really look at is adherence to our solution. So what I want to spend the rest of the time talking about is the idea of how we build a process that enables us using Django Tools to keep people excited about the application and making sure that they stay engaged. So this is a obviously a graphic that I created to just kind of illustrate our process. It's a pretty simple process and it's designed to be simple on purpose. Our first phase is a sketch phase, second one is prototype, and the third one is build. So we obviously

Speaker 1: this a lot of this is going to be really kind of base level, you'll probably already have gotten all this stuff. But The sketch phase is designed uh I'm sorry, let me give that. The sketchphase is designed to capture the ideas really quickly and easily The prototype phase is designed to deliver something that people can play with. Sort of like if you took your sketches, you're working on a painting and you took your sketches and handed it to other people and said, you have lines to it as well. And then the build phase is where we actually build the application. Before we begin sketching, there's three things that we try to focus on doing. Because otherwise, who are we sketching for? Maybe our own curiosities or whatever. We need to make sure that we have users. And this has been something that we've uh talked about

Speaker 1: in the projects that we're working on pretty consistently. Is nothing about me without me I wish I had been clever enough to come up with that, but this was actually brought up in a seminar. And the idea is that if you're building a tool for me and you don't include me, then what are you doing? There's no point in continuing with your application if you're not including me in the process. And by me I mean me as a user So one of the things that we really focus on and spend a lot of time on is identifying uh what the problem is and then what the solution is. How many of you guys have read uh lean startup or running lean or any of those? Okay. So I would strongly, strongly encourage you to go out and get those books.

Speaker 1: There's some really great practices in there about identifying whether or not we're actually solving the right problems when we're building software. Um I'm gonna say this a couple times. You guys and us as developers are pretty intimidating people often. When we work with our stakeholders, when we work with our users, um w We know a lot of things about specific pieces, and it's sometimes it's a real challenge to have a conversation with us So we might look at something and say, oh, I seem to have developed a solution to this, or I know what the problem is, so I'm going to go solve it And then if we don't encourage users to participate in a conversation with us, then we end up kind of drifting down the road, uh rabbit trail, and building something that doesn't actually work.

Speaker 1: Doing this, if you guys get running lean and read through that book, I think you'll find that there's some really great methods in there for validating what you're trying to do before you actually do it. A couple years ago we were working with a client, Korea, we've th we've had a good relationship with. This was about the fourth year of working with them, and they came to us with an idea for a new project. And it was pretty exciting. It was giving me an aggregation tool that did a whole bunch of cool stuff. And They were starting to allocate budget to it. They were starting to build up the the kind of the internal political uh approval and we were all set and ready to go. And I said I had just finished reading this book and I said, well let's Hold on a second, let's make sure that we're trying to solve the right problems.

Speaker 1: So we propose, we worked with the stakeholders, and we propose these are the three problems we're trying to solve. And we sent that out in the survey to their constituents And we used Google Forms and they went through and rated all this stuff. And none of the problems came back as rating higher than, say, a 3 on a scale of 1 to 10. And it was a good thing that we did that because what ended up happening was the stakeholders said, well, we're not going to allocate all this money towards this if we don't know that this is a problem that actually needs to be solved. These aren't used we perceive it as a problem, but our users don't actually see it as a problem. They have a whole different set of problems, which came back as a unique opportunity for us to take advantage of So being able to identify what the problem is is super super

Speaker 1: important. Using Google Forms to do this is one way. Obviously user interviews is another. You can sit down with users, talk to them. uh talk about what you know what are the problems that you have in this regard. Uh if we go back to the walking idea, what prevents you from getting up and walking around? What what are the kinds of things that you could do that would um um offset or or give you the opportunity to take a lock that maybe you hadn't thought of before. So having and understanding this problem piece is 50% of what you need to understand before you start. The other 50% of it is what's the solution? So if you can get an agreement from the people that you want to solve a problem for, you can work with them, they can help you identify on a priority

Speaker 1: what are the top three things that I need to solve. problems that I have. And you can create solutions for this. And this is just Google Forms, right? It's just you're just typing stuff out. You haven't written any code yet. You haven't done any drawing, nothing. They're just talking with you, you're dialoguing, you can develop some solutions, coming up with ideas, and you can use this now to develop your product. This may suggest to you what your primary function of your product is When we were looking at the fly fishing app, one of the big problems that I had was I would come off the water and three days later I couldn't remember what had happened, never mind what I had been doing the year before They had no way of knowing what the population difference was between one year and the next. Fishing reports are you know not very good for that kind of stuff.

Speaker 1: So identifying what the problem was, we talked to a bunch of other fly fishing folks and we asked them, what are some problems Well, I can't ever remember what's happening. I know I have these flies available to me, but I don't I don't remember when I'm supposed to use them So the solution was, well it's a simple simple diarrhea. You just track what you're doing, select the weather, some basic science stuff, and then you've got the information that you need to do. So that coming up with a solution was based on specifically what the problem was For another project that we're working on right now called Manage My Fatigue, we're working on developing an app that helps people manage their fatigue levels, specifically to start folks with traumatic brain injury. So we needed to be able to look at what are the problems that people have when they're trying to manage their time

Speaker 1: energy retention or or or keeping their energy levels up is a is a real uh struggle for this population. So knowing how to identify what were the problems. Something simple that I may not have come across was I need a visual cue that tells me when the timer is up I need, not only do I need some sort of messaging, right, some haptic response or something like that, but I need the screen to actually change so that I know something's happening Okay, little stuff like that. So these are different pieces that come out of first identifying the problem and then identifying the solution The last little piece of this is building user advocates. These are people who in essence, as your users, become your friends. In all honesty, you develop a trust relationship with them.

Speaker 1: You ask them questions, they give you the feedback. You need to have a thick skin because if they're honest, they'll tell you when something you're doing sucks or when something you're doing is great. User advocates are somebody that you can go back to consistently. They'll be your early adopters. They'll be the people who are passionate about what you're doing as well as you, but they maybe don't know how to write code. Often um they have a vested interest in them in knowing that this thing works for themselves. So they will work with you and are much more tolerant of the mistakes you might make in your assumptions as you go along and are happy to help set you on the right road. Additionally, these user advocates are somebody or is a group or a population of people that are going to stick with you through the whole project, beyond just your initial launch

Speaker 1: They'll continue to stay with you. They'll be excited for you. They'll continue to provide you feedback. These are the folks that you'll get an email from at midnight or four in the morning. Hey, I thought about this or hey when I did this this didn't work, etc. Or you forgot to f turn um debug off, and now I'm getting code on the page. The sketch phase is about pretending. If you identify the problem, come up with some solutions, your users agree, yes, those are great solutions, those are things I'd be excited about. The sketch phase is about pretending that you have the thing already. So you're wireframing how many of you guys actually wireframe in your projects? You wireframe out views and that kind of stuff. Okay. So this is incredibly inexpensive, and if you're not doing it, you definitely should

Speaker 1: This is allows you even with just a piece of paper to draw out what you think the view is going to look like, maybe what the forum is going to look like, what the feedback potentially is going to look like. This will save you so much time and effort You can use Google Drawing if you if you don't want to just sketch and you're afraid of doing sketching. And I'm a big fan of a service called Balsamic. I have no professional relationship with them other than I'm a paying customer. But they um they've got a great set of tools that you can build together UIs in a matter of minutes uh because they've got a library of different kinds of widgets. The principle is not this is my design I'm giving you. The principle is this is a potential experience. Can you use this? And that's why going through this process using this piece of it

Speaker 1: is a really, really important part. You can get users and build momentum by doing this. So If you have your user advocates and you start testing this stuff with them, ask them to share it with other users so that those folks are also excited about what you're doing. This is a screenshot of the timer piece and as I was referring to the left, you'll see the normal countdown timer, and the feedback we got was I need some sort of visual cue that the timer has changed, so we turn the screen red under five minutes. There are some assumptions I made as a designer in this screen which turned out to be wrong. And it's a lot around the icon iconography. All across the top, uh

Speaker 1: on the left and the right, and on the bottom left. There's a lot of icons on the screen. And justifiably so. It's a mobile view uh I need to fit a lot of information and functionality into a small screen. Problem is, feedback came back, I don't know what these icons mean. Now I don't know if you guys have struggled with this or not. I recently wrote a blog post saying to get rid of all icons, to strip everything out as much as you possibly can, because there's no common vocabulary around most icons Right? Most of the icons we look at are interpreted by the designer and the team that's building it. They're not based on a universal principle of understanding. There are a few, yes, but most of them, I would argue, are not If you use this process, you can iterate quickly.

Speaker 1: So I can draw a sketch, I can put it in front of users, can say what do you think? I've even done things where drawn something out, taken a picture of it with my phone and emailed it to them. Tell me what you think of this That can go very quickly. This is useful because you can build momentum, like I said earlier, you get people excited about what you're doing, you're responsive. So someone tells you something. you can push that right back to them if you have say a user advocate group of around five users. If you have more, say 20 plus, you can synthesize all the feedback and you can say this is what other people are saying Here's all the different stuff, the feedback, all the different input I'm getting, and then return that to the user so that they have something that they can understand. Making it accessible is super important too. How many of you right now, if you had to, could actually type out your Basecamp

Speaker 1: password? If you're using Basecamp. So a couple. Most of the users that I'm working with have a hard time even with login screens. And not because login screens are necessarily difficult, but because they have so many services, how am I supposed to remember what this password was So while I really, really, really, really like Balsamic, um the login process is difficult for some of my users. So if I give them access to some screenshots, They have to log in and in order to leave their comments and I will often get emails I don't remember my password. They're emailing me because I'm the face that they're interfacing with even though there's a root I don't remember my password. Same thing happens on Django apps So I'll back stuff up with a uh PDF

Speaker 1: of the of the actual wireframes in case that happens, I can send it off to him in the meantime while I help figure them out. Um and I can even just use raw HTML. I worked on a project for helping kids with depression talk to their parents about depression. And we built a game. And when we were initially got started, there was a lot of things that we were trying to figure out. And almost all of our prototyping that we did was all just raw HTML with no styling. Because uh all I need to do is understand what would happen if the user I mean all I needed to know was does the user understand what will happen when I click something? Do they do they get the idea that I can do something and then something happens? So that was easy to accomplish with just real basic HTML.

Speaker 1: Then it's gotta be fast. If it takes a month to connect with your users, send them stuff, process it, and then get back to them, you're gonna lose your users are gonna lose interest. And or they're going to forget what they were already working on with you. So you've got to be fast, you've got to be responsive, you've got to get back to them quickly. Okay. This is my favorite part. Prototyping. So I had the good fortune of working with uh a guy named Rob Hudson and a guy named Percy Perez And I wish that this idea was my unique awesomeness that I came up with. But actually it was these guys. And at the time I was a designer just doing front-end design. And these guys were really smart

Speaker 1: Hang on folks. And we kept having this problem going back and forth around, I wanted to do this, but I want the functionality to be you know, X, Y, and Z, and they said, I don't know what you mean by X, Y, and Z. And I'm like, well, what do you mean you don't know what I mean? It's right here. Look, you can see it on the Photoshop comp. It's all really clear. And their pushback was, I don't know what it actually does. So I don't know what kinds of things I need to do in the background. So We switched. And they said to me, you build me a template first and then I'll do the modeling after. And I'll create the views and all the data models based on what you give me as a template. And I hope I'm not outing them about that. But the th that kind of turned my whole brain around. So the idea is that I'm not gonna start with my dataset, I'm not gonna start with my views.

Speaker 1: Now I'm going to sell with my URLs. I'm just going to create a basic template. And I'm going to start there and start showing the things that I want to have that one on the screen Uh for that reason, uh I'm sure there's different I've have forgotten by now, but there's different Django starter kit libraries. I just usually start with um Just a basic J-Go install and then static static files and flat pages. So that I can start building stuff out and getting access to the templates and start iterating in front of users. So it's so quick to be able to m you know Then I don't have to do south migrations or whatever, depending on the version you're on. So I can build out the templates, modify my HTML, make it do stuff in front of my users, have them give me feedback and make changes. So this is something instead of pair programming with another developer, I can pair

Speaker 1: program with my user. We can sit there together. Obviously they're not programming, but they can look at what I'm doing and say that makes sense, it doesn't make sense, move it up here, I don't understand what you're doing, etc. And then some of the front-end frameworks that make this go quickly. Good of Rootstrap, Gumby, Foundation. What you think about those as far as a front-end development framework for later on is a different question. For me, in this phase, it's really about do I have this solution nailed? Does the user experience make sense? When the user clicks on a button that says add note, does that experience feel right to them? Are they excited about what it is that 's happening? The other thing that I did

Speaker 1: probably about four years ago is I completely stopped using Photoshop or any other 2D mock-up tool at all. And the reason is I cannot get the same feeling and the same experience in a 2D mock-up that I can with a template or something that I can click, especially if you use responsive design. If you're using responsive design, you can build a model that works on a phone and is accessible by a URL. So you click it, it does something. You click it again, it does something else. I can't emulate that in Photoshop. So what I found was I was spending a ton of time and effort on my mock-ups to communicate all these different views,

Speaker 1: you know, um inboard messaging, onboarding system, uh, you know, all kinds of stuff And it just was not working. And I figured, gosh, if I just get rid of Photoshop and stop doing that altogether and just jump right into the HTML then I know that I can be able to communicate things quickly and easier and get the feedback I need in order to keep things moving. And so far we haven't regretted it. It's been a really positive experience not using Photoshop as the markup. Yeah, if it if I can't touch it, it doesn't exist. And again, another reason to not be using Photoshop. So if I can't if I can pick up my tablet and do things on my tablet, if I can pick up my mobile device, I can pick up my laptop, whatever, and actually do something, even if it's completely fictional

Speaker 1: That gives me better feedback than having a user look at something and pretend to click it. Has anybody heard of heap analytics or kiss metrics? Okay, a few people have heard of KISS metrics. So KISS metrics is kind of this awesome data opportunity. You can use KISS metrics to track all kinds of stuff. For instance Let's say you have a tool and you want to do a conversion from a user who's registered all the way through a fulfilled shopping cart. You can build a funnel report in KISSMetrics that tracks the entire experience for a specific user and tells you where they fall off So I've used KISS metrics to look at online

Speaker 1: education programs for advocacy stuff for for instance uh traumatic brain injury and we knew that at some point users were falling off. So the idea was we want to identify what was causing that fallout, and we use kit 's metrics to look at the data and come back. Heap Analytics, I think, is relatively new. And what they've done is they've kind of done this similar thing for free. So you plug in a little JavaScript on your HTML and you can use this on your prototype or your actual build. And you can look at the data and all the fall-off and all the different conversion rates, etc. It's pretty awesome. So if you remember, I showed you a screenshot earlier with icons. The feedback we got was I don't

Speaker 1: understand how the icons work. This is a screen gap from the alpha version of the app, the management fatigue app. And we converted to text for navigation. And it's been way more useful because users are aren't stumbling over what the icons mean. They don't have to learn a second vocabulary as long as they speak English. or can read English. So they can use this app and jump around and can see things quickly and easily, and there's much less cognitive load as far as, well perceived cognitive load as far as trying to understand how the UI works. Like I said, using templates in Django flat pages, I just install it, you know, do a basic install, get things built up, you can start building your UI off of uh Django flat pages and building your

Speaker 1: URLs. Okay, so I just recently started using um Angular on my front end. And basically the way we do stuff is we use uh Django for all the backend stuff Then we use Django REST framework for the API. And then everything else is done in Angular on the front end. We're still working on u uh user authentication, because that's kind of a tricky way chip. But what's cool about this is the work you do in getting your prototype ready is actually building your app if you're using one of these front ends. So you can emulate all your data stuff with JSON, just like you would fixtures, and you create your JSON data, set it aside, and do your API calls against that JSON data file.

Speaker 1: You still haven't built any data models. You still haven't messed with anything on the back end of the database. It's all just in the front end. But you can get pretty damn close with this. And it's it's to be honest with you, I have a ball. I actually love doing this stuff. Um I haven't played I've done a little reading on Ember and haven't um played with it much uh and I left backbone uh uh as soon as I've done Angular. Okay, so built. So you've integrated through this with your users, you've put out releases, you can set up a you know an HTML just static site, they can access stuff, they've played with it, they've given you feedback, and now you ship it. And I would strongly, strongly, strongly encourage you to use something like heap analytics or KISS metrics. plug that in and now you're starting to iterate not only with user feedback

Speaker 1: but but with user data. And I can't tell you how many times I make assumptions about how something works or what the user experience is only to have this data show me that it's completely in the other direction. So I am a big fan of Django Rest framework. Um I think it's a fantastic tool. But one of the reasons I love it more than some of the other API tools is because of this. So I can build an API and play around with stuff and I can test alternative methods. So obviously I'm in the build phase now, so I'm building my data models, I'm you know getting real database stuff moving, and I can build my front-end at Angular or whatever

Speaker 1: however I do it, old school Django, whatever But this tool gives me the opportunity to have a whole other interface that shows me alternative views. What's neat about this is I've actually shown clients Um I'm sorry, not clients. Users. This view with the with Django Rust framework. How many guys are using Django Rust framework? Okay, sweet So I've used this with other uh users, sat them in front of it and they're like, oh yeah, I can see. They get a list view with the with the creation thing. You have to translate a little bit for them, but it's can be a useful exercise in How do you want this to work? And in fact, this method I used on a recent project where we had a list view of stuff. And because it's a single-page app, I was able to make the add screen and the list screen in the same view.

Speaker 1: And the user really appreciated that because he didn't have to go back and forth between page refreshes. And the idea came from how those are set up Collecting feedback obviously is really important. I highly recommend you systemize it somehow. Depending on your population, GitHub can be really useful. If you do use GitHub, you need to know that they obviously have to create their own account and you need to work through them. What does it mean to submit a ticket and how do I make it useful? Google Forms is another great tool. I use Google Forms all the time. Really, really, really like Google Forms. Django Feedback is a side project that I had a while ago. It's pretty outdated at this point. And the reason is uh I had a whole project and what I now end up doing is

Speaker 1: It stopped make asking the user to please tell me what browser they're using, what version, what all those other things. I just when when I have a fee any feedback form that's integrated into my systems I'll now just add in that second line and I send myself the user agent and it tells me everything I need to know. So, well, most everything. And then they all give me the feedback so when I get that email, that feedback email, I get their note with all their user agent stuff Makes it easier on them because they don't have to worry about translating something that they don't necessarily understand. I h highly recommend that you try to keep data collection as simple as possible, at least in the beginning. So you use a cer one service for data, one for feedback. If I added one more to this, it might be one for monitoring, like new relic or something like that. But try to keep your data sets as small as possible

Speaker 1: because those data sets will grow quickly, especially if you continue to solicit feedback from your users and they're excited about what you're doing, for instance via Google. rule forms or something like that, you'll collect a database with lots of records and lots of feedback. So The process we use, sketch, prototype, and build, has been really successful so far. We've had a lot of good experience with it. We've saved a lot of time by cutting out some of the Photoshop stuff. And by replacing it with live templates that we're building on has been really useful. Special offer for you guys. I built templates for both the problem and solutions interview piece. If you're interested

Speaker 1: in using those in your own work or taking them and run with them, you can just go to daywoman. com slash email sign up Uh send me your email and I'll uh I'll send you the problem and solution templates. Okay. Any questions? Are we doing out of time? Oh sweet. Okay. Any questions? Anything else you want me to dive in a little bit deeper on? Do you have any quite

Speaker 2: Thank you very much. That was uh um very salutary advice. Um I don't know what you think about this, but one of the things that shocks me most about software developers is how often they don't use the things that they're actually building themselves. So Um they are entirely reliant on the user for feedback. Whereas If you build something and you are also the user as well as the builder, if you've got to live in the house that you've built or eat your own dog food or whatever metaphor you like to use, then That loop is is very much tighter and um I

Speaker 2: think it should be compulsory by law obligatory for developers to use this stuff. And you're not even allowed to develop something unless you're going to use it.

Speaker 1: Yeah. Yeah. So my my final way to say is do do uh developers eat their own dog food for lack of a better term? I definitely agree. I think that we do need to use the tools that we um that we create. One of the things that's really challenging is uh especially with most of the populations that I work with, there's no way, even if I use the tools, that I'm gonna completely understand the problem set that they have. This past spring I got to be in uh at Coastline Community College where we were testing to manage my fatigue app and I sat in a room Uh we had three, I think three sessions, twenty students each, all had traumatic traumatic brain injury. There's no way I can fully understand what it means to have a traumatic brain injury. So I I would definitely agree

Speaker 1: we need to you know eat our own God food but we also need to become friends with our users because they're gonna communicate to us whether it's easy the first time or not what it is that we're doing and whether or not it works That makes sense?

Speaker 2: Certainly it must be easier to be your own user when you're writing a CMS than doing something like that. Correct. Thank you very much.

Speaker 1: Yeah

Speaker 3: So it seems like you're doing a lot of user-central design, which is awesome. I would love to see all companies do that. Uh my question is do you ever act or did you ever need to account for users bias? Meaning, you know when Henry Force said that people ask for a faster course. If you ever have to account for people even use some solution that's not necessary

Speaker 1: Yeah, so um the question is do I ever get recommendations that uh

Speaker 3: the question is do you have mechanism in place to compensate for this bias e or maybe you just never needed to because you're users are you select your users in a particular way so that

Speaker 1: no um so for us one of the challenges is we get a lot of really good feedback so managing all of it is about time and budget So many of the things that if they're not in that specific problem set that we established in the beginning, then we backlog it and figure out when and if I've actually taken things out of that and put it both in front of my users and said, hey, what do you guys think about this? Right? This may be a really good solution from one user. How does everybody else think about it? Is this something that we need to consider? Do we need to change our priority? So it's just about conversation. Thanks.

Speaker 2: Yeah we uh we are we are the one so okay here's another question then. Um I used to work at a uh university where uh I built as a web publishing platform uh for them. And I was the biggest user of them of this. But we had uh another fifty or so users who were also collaborating on on on content and I was in quite a fortunate position because even though my users were often completely wrong about how this should work and what it should do I was also the most important user, the biggest user of the system.

Speaker 2: What do you do when when actually the feedback or the desires you get from users Doesn't follow best practice or isn't actually going to do the things that they think it's going to do or or your users want things that they should not have.

Speaker 1: Yeah, so that's a really good question. Um What do you do when your users make recommendations that either they might be flat out wrong or they might be recommending recommending something that's not in the best their own best interest. Um For me, it's about being able to dialogue with them. It's about being able to if you have that trust relationship, then you can say to them, no, that's not a good idea. Or if it's really important and you don't understand, which I think is a big issue a lot of times, is oh help me understand why this is important. Or is there something else that we can do that helps you accomplish what you're trying to do without actually compromising the law or violating copyright or you know there's a lot of misunderstanding. I've had people go, well why can't you just copy the source from that page, put it in that page, and you'd be good to go.

Speaker 1: Well because that's an you'd Stealing someone else's IP and you don't look good when you do that. So it's about building that trust relationship.

Speaker 4: Um one of the things we find is extremely difficult is taking features away. Once you put a feature out there it it's really hard to tell a user that no you can't do this anymore. And do you have any experience or thoughts on on how you can do that in this in this process

Speaker 1: Yeah. So the question is how do you take features away or avoid the issue altogether? For me, it really goes back to identifying the problem solution set. If if you only have three solutions, then you try to make those solutions as simple as possible, and that restricts the amount of stuff you actually produce. So Uh the fly fishing app is a great example. Um we wanted to do all kinds of cool stuff like geolocation and you know yada yada go on and on and on. The reality is it was cost prohibitive to do it. And if I had released that as a feature, I would not have been able to support it. SMS messaging is another thing that we run into a lot. We would love to be able to implement SMS messaging.

Speaker 1: We have the code to be able to do it. However, if you implement that, you now have to pay for it. So there's an unforeseen budget ramification. So for us it's about shipping things that are as small as possible. When it does come time to actually have to remove something, that's a marketing opportunity If you can take the time and justify why you're doing what you're doing and explain it well to your users, it gives you another chance to connect with them. You may piss some of them off. However, you do get to have an honest dialogue with them. I don't really Yeah, I think it's the bucket.