 Good morning. I'm Jessica Roper. I'm a senior software developer at Spiceworks. We make software applications for IT pros, although this will not have anything to do with that. Over the last five years, I've worked on a wide range of products. I've had the joy of working directly with our clients, working directly with our users, and working with a handful of different product managers over those five years. And some of those projects have gone better than others. And so I want to talk about how I've learned to build better applications the first time. This talk is geared a little bit towards early career developers, but these are tips I still use and will probably continue to use for the next 20 years. The high-level things I want to cover are three really main problems. Feature creep, managing expectations, really making sure that everyone understands what is going to be worked on as well as when those things will be completed. And how to avoid long design iterations, really making sure that I don't discover a fundamental flaw at the end of development instead of at the beginning. Some of the pitfalls that I've experienced by not following these tips are delivery deadlines that extended weeks, if not months, past what I expected them to be. Having really poor manager satisfaction, I build a bunch of tools for internal folks, so they go right to your manager and make it very clear that you did a very bad job. And spending time on features that it turned out no one used. I actually at one point spent two weeks on something, put it out there because I thought it was important and then no one actually cared at all, including the person who requested it. And so there are dozens of other tips and tricks out there, but these are the ones that have helped me prioritize which features are the most important, making sure I'm iterating through the design process as quickly as possible, and really making sure I'm setting expectations at a reasonable level. I've used these tips by myself in groups of two or three, and even in seven or eight, I think they mostly apply to about all sizes. While I talk about these tips, I'm going to use an example project that went not so super well that I'll call the sales audience sizing tool. And what this tool was geared to do is give our sales associates an idea of how many users could we target for something. So I want to know how many users in Germany are subscribed to our email that have HP devices. These are the kinds of questions we're trying to ask. In the past, before this tool existed, our sales associates would have to figure out what this request was. They'd throw it over the wall to our business analysts who then dug into the data, ran SQL queries and then give the results back 48 hours to 72 hours later. So we're talking three days till they got their results back. So I really wanted to take that three days and turn it into 10 minutes was our main goal for this particular product. The first tip I have is define the problem clearly. Really, before you get started, you want everyone to make sure they're focused on both the same problem as well as the same user. There's a really different product that you're going to build. For instance, if you're building a banking application for a banking manager, then if you're building a banking application for a bank user, the banking manager needs to know everything that's going in and out of the bank, how many loans they have out, what the state of all those loans are, both sides of every transaction. But a user really only needs to know what is going on with their individual account. And some of the kinds of questions that this leads us to ask is, can prior knowledge be required? If you think of CAD-like products, not great picture, but if you can see here, it has a bunch of views of whatever it is this person's creating. There's a bunch of icons that might be confusing. This is a product that we expect users to have a lot of education about before they go use it. So it's okay to expect them to have all this knowledge and not have to build into the tool what's going on. Other questions include, do other products need to integrate with the tool? Or do you need to integrate with other products? Are there tools that expect to be able to use your API or APIs that you need to understand before you get started? Are there any designs that everyone is used to? So if you have a standard of knowledge, you can always have a user icon in the top right. You should probably leave it there. You don't want to give a new product to your users and suddenly have them searching to figure out how to log out. In my sample project, the audience sales, sorry, the sales audience sizing tool, we knew that we didn't want them to understand the data they were looking at. We wanted to display it in a way that was easy to comprehend. It needed to be really fast that three days has got to go away. And we wanted to have a small training session to be given to everyone so they get a 15-minute training session from me before they actually start using it. And something else that really helps in this phase, especially when meeting with the clients, is to really write everything down. Write down the features that you've decided are most important, who the user is, and especially the timelines you've talked about. I don't personally make my managers sign off on what we've written down, but when we have follow-up meetings, I always go back and refer to that and constantly make sure that we're all looking at the same kind of set of expectations. The second tip I have is observe the user. If at all possible, observing your actual users in their real environment is so valuable, it gives you a huge insight into their day-to-day problems, the workflow that they have, you can kind of see for us with IT professionals, they get interrupted all day long. So if they're trying to do something that is really hard to think about and takes 18 steps, it's going to take them a really long time to finish it because they're getting interrupted about seven times before they can finish what they're trying to do. And if you ask your users what they do, it turns out they almost never remember exactly what they're doing. Although when we do ask them, we always say, what did you do yesterday? Rather than what are you do generally, it helps them kind of really focus on what they really did. So if you can't see them and you can't ask them, you can at least really try to focus, what did you do on Monday, like walk me through your day. And a lot of times they leave stuff out, so just keep that in mind that they may find something irrelevant that you think is relevant, so if there's any kind of outlier that you're looking for, make sure you ask about them. In a lot of cases, you won't be able to observe your user or even interact with them. It's either not allowed or just not a possibility. And there are other ways you can kind of watch them. So instead of talking to them directly, you can observe their behavior. And you can do this through mostly data. So if you are able to use Google Analytics or usage stats and kind of walk through, is there a point in the process where they start to use a feature and then they just don't ever get to the end feature or they get to the first page and they never ever come back? That's an indication that they were interested in the feature or they're interested in the problem you were trying to solve, but it wasn't completely what they were looking for. Is there anything they do a lot? They really love a certain feature. Maybe that's something that can be expanded on or something that's clearly really critical for them. And is there anything they don't ever do? That a page they just never reach or something they clearly don't care about? And I can kind of tell you that features in that area are probably less important to your users. In our sample project, we actually did the wrong thing. We observed the wrong user. I was automating the BAs, business analysts, and so I observed the business analyst. And by observing the wrong user, I ended up making a tool that they could use and one that was very confusing the first time we put it in front of a sales associate. They first were asked, okay, what you know demographic do you want? Do you want the United States? Do you want Germany? And they were like, I want to know if I have HP devices. Like why are you asking me about the United States? And so we had to completely go back and actually like at the end then go back and format everything and restructure everything. And it probably should have taken, you know, hours if we had designed appropriately in the beginning or observed the right user, but instead we found out at the end and we had to spend days doing all of that work again. The third tip I have is focus on the majority. So in this quote from Scotty from Star Trek, you can really replace Starfleet captains with users or clients or product managers. At the end of the day, they want everything and they want it now and they really want it their way. But it turns out they don't really need everything and a lot of times they'll be off the cusp. It would be cool if we had this feature comments and it turns out half the time the people making those comments don't intend to use that feature. And so at Spiceworks we use a rule called the 80% rule. We try to focus the features we care about on problems and things that will work for 80% or more of our users. And so this means that if there's a problem that solves a problem that everyone has, so in IT, you know, really everyone needs a help desk. That's a problem we go solve. It's highest priority. But something that maybe only 80% of our users need some or something one off that a user is requested which is I need to track a fleet of cars transporting from one state to another. There's maybe three IT pros that need that so it's cool that he needs that but it's not something that's really going to fill, provide value for the rest of our user base. So that would be considered a really low priority feature for us. When I'm working with the sales audience sizing tool, because I was able to talk to account managers and even the, you know, VP of sales, when they would request things I would always ask, you know, how many other accounts does this apply to? And most of the time they'd say, oh, you know what? It's really just me and maybe this one other guy. Maybe that's not as important. So it also helped them to understand why we wouldn't go build their feature. Again, you can't always interact directly with their users. Maybe you don't have users yet and you're trying to figure out what you would want to go build for them. If you don't have any users that would be the case to go research the industry as a whole. What other products are out there that people are using? Maybe there's a mesh that you could kind of fit in or maybe there's a problem that's not being solved that you can go solve. If you do already have features, again, going back to look at the features that are most used will give you an idea of what's really valuable to them and the features that have highest drop off. They thought there was value there. They would like to see more. And the features that no one uses, those are probably ones that they're not getting value out of or they don't care about and so maybe don't focus on those as much and cut your losses at that point. The next tip I have is prototyping with users. It is really tempting to just jump into development and not waste time iterating on designs, but in practice I found this to be much faster and less a waste of time. Again, if we had used this prototyping technique which we did not have for the sales audience sizing tool, I would have been able to sit down with our users and really quickly discover wow that flow is confusing and spend hours maybe even minutes on it rather than the days that I ended up spending at the end. Prototyping is a really important technique for getting early feedback. It helps with design and also with discovering the flow and really just the general look and feel that your app is going to have. So that would be the aesthetics. A good rule of thumb that we use is after about five users, we kind of take all the feedback and then iterate. After five users, you mostly get the same feedback. So it's good to just kind of keep working on iterations. And obviously if you don't have real users, this one you can do with anyone. It can be your coworkers, your friend, your spouse, anyone who has any ability to understand the product you're working on and help you test. Does it make sense? What am I trying to do? Can we work out a better design? There's a great e-book by UXpin that's free that goes in depth on prototyping and the next things I'm going to go over much more in depth. So feel free to check it out. It was a really good read. The first kind of prototype is low fidelity, low functioning. This basically means it doesn't look a lot like the real thing and it's not super interactive. And so a good example of this is paper prototypes. The way that you use these is you would kind of have all these different views at the bottom. You'd display the first one to your user and ask them to do an action. And they would tell you I'm clicking on the arrow, I'm clicking on the middle button and you then change the view to represent the next page they would see. If they click on a dropdown, you can add sticky notes. I've actually used just sticky notes and a myriad of them to work through design iterations to say, okay, I need to add another filter. Should it be a tab on the side? Should it be a dropdown? Let's go through how that looks and what makes sense for the user. The key things you're focusing on with this kind of prototype is really flow. This is not about the color, the exact color or the exact size. It's about how much of the screen do I want a button to take up? Where should it be? What should it say? So again, not the exact spacing between elements or the exact picture that you're going to show but really more about this kind of fundamental flow. And this is probably the prototype that's fastest to iterate on because again, you can just pull out a pack of sticky notes and go at it for about an hour and you can really go through four or five in that time. The second kind of prototype is low fidelity, high functioning. So again, it doesn't look a lot like the real thing but now our interactivity is there. And so a good example of these are wireframes. We don't care about the actual visual. I don't care what a post really looks like or what a picture really looks like but what I do care is how is the usability. If a user is trying to do something can they understand how to do that next action? Are there any elements on the page that they don't use at all that I really wanted them to use? And is there a time when they know what action they want to take but they just can't find it? They can't figure out how to log out for instance. And so in general these should really mimic your true events and a really good use case for these is if you have working with designers and developers at the same time you can use this to kind of hand off to your backend developers so they can start working on functionality and hand off to your designers so they can kind of flesh out the way everything else needs to look. So this is a good way to provide kind of supplemental low level documentation to get everyone moving really quickly. The third type of prototype is high fidelity low functioning. This is basically all about visual. So when you're working with the Steve Jobs of the world who really really care about how everything looks these are great to walk through with them. You're now focused on exactly what color should it be. What is the exact spacing. Should there be a border around the table. Should it be shaded. Really all of those fundamental components and obviously this isn't the time to have like real data or real anything in the backend. So you'll see that you know this has the exact same number over and over again because we just put a number in there and went with it. So it's not important what it does. It's only important how it looks. Oh sorry. There will be there will be a hint of the flow in the mock-up so you'll kind of focus on each individual page. You won't you know show every single action but you will kind of show how the pages are different. The last type of prototype is high fidelity high functioning. This basically is just shy of the real thing. It's kind of like an HTML mocked out application and this is focused on everything. You want everything about the way it looks and feels to be accurate and all the actions to subtly represent what they would do. Nothing in the back ends wired up. There's no real data. There's nothing real but it feels like it could be. I think the best use for this is when you're working with completely outsourced programmers. So if you need to hire a contractor or someone just not that you can't work closely with you can hand them this and say this is exactly how I want it to look. Exactly how I want it to behave and there's no question about what they're going to go do and you don't have to worry about any liberties they'll take with your design. The next tip I have is under promise over deliver. So there's a Star Trek video with the captain and he has an emergency and he really needs repairs and he's on the phone with Scotty and he says how long is it going to take? Like I'm in an urgent situation and Scotty tells him it's going to take eight weeks but you don't have eight weeks so I'll do it in two and that's when the captain says have you always multiplied your repair estimates by a factor of four and he has. He says how else could I keep my reputation as a miracle worker and I think be like Scotty be a miracle worker. You don't want to have every development hour plan to just build the product because then when something goes wrong you're running around like a maniac until four in the morning trying to get it done and that's not an ideal situation for anyone. There's a good rule of thumb that we use in development at my company is to double the dev time we expect plus testing in bucks and the reason we do that is because there's always overhead you don't expect so maybe a machine has to be ordered or the data has to be restructured and a lot of times they'll be refactoring and complete reworks that maybe you didn't anticipate so if I had you know realized that it was possible for the flow to be wrong in my original project then I could have doubled that time and we could have been able to switch that without having to extend our deadlines. Another thing that happened to us in that case was we actually had data corruption about two days before we were supposed to present this to the entire sales team and it turns out it took five days to put the data in there so obviously we could not do that we had to completely reschedule the entire sales team for the later weeks just because we had to rerun the data something we didn't expect to happen at all if we had added time for that they wouldn't even have known anything had happened and in general if you have extra time let's say you've overestimated then now you get to grab a bonus feature something they didn't expect to have but they'd like to have that's now an extra thing and makes you look awesome instead of being late The last tip I have is create a feedback loop so this is something we do a lot of time at the end of a project but it's something you can do at the beginning of the project too we actually have an online forum where we do feature requests so users are able to request features and then vote them up so we're able to easily see which features they cared about the most how many are at the top that are really similar that's maybe a product we could then go create and so that's been really valuable for us to be able to identify what people really care about there are other ways to collect this feedback so one is gather your own usage data figure out which actions and statistics you care about and collect them so for my tool I really actually track every page they see every search they're doing and because I'm able to see that I was able to discover that they had some confusion in how to use the search tools and be able to address that in all my trainings from that point forward and I now see when I look at that data that people are searching the way that I expected them to so I've been able to adjust for that by using the feedback that I was given or that I collected other things you can use are Google Analytics so Google is a great way they track session times they can actually tell you how far through a flow that you got and so they it can be a good way to kind of measure did people get to the end of the process are they spending time in my tool is it providing value to my user and finally you can just ask them if you have a tool that gets uninstalled ask them why give them really easy options to really get you to understand what it is that they're having a problem with when it comes to your tool so in summary there are a lot of problems that could be addressed but the ones that I've covered are setting expectations and timelines I think making sure that the problem is very clearly defined and that it's written down helps everyone have very consistent expectations and making sure you under promise over deliver it's so much better to have an extra feature than it is to be two weeks late I guarantee your managers will be much happier with that and to identify the highest priority features features is really all about understanding the user you need to understand what the problems are that they have how they're thinking about things what are they using and this kind of indicates to you what is the problem that a majority has what is the best kind of feedback loop that I need should it be data or should it be forms how can I reach out to them and I think the main way to iterate quickly on designs again understanding your users so you have a good base of designs that you want to start with and then just prototyping at any of those levels is really really valuable I really have gone through I think almost every project now we do prototype and it only takes a day or so and it has saved us probably weeks in dev time in the end so it's proved to be extraordinarily valuable to us so this is obviously not an inclusive list of everything but it's the ones that I found the most valuable to help improve my timelines so they're consistent accurate and reasonable helped me determine which features are the highest priority so I'm not spending two weeks building a feature that no one cares about and someone actually complained that I built which was really disappointing and making sure that all of my stakeholders have reasonable expectations whether those are my testers my managers my users my clients whoever it is so that they kind of know what to expect and when to expect it does anyone have any questions or other tips or tricks they think I should have shared so the question is there's four types of prototypes is it the same person working on them or you know or different people it kind of just depends so when we do wireframes a lot of times we work with our designers a little more closely for that paper prototyping I personally do myself mockups it kind of depends for mockups if the product mostly exists and I'm just tweaking it then I feel pretty comfortable doing that but I do bring my designers or UI people in as I need to so for us we kind of really just focus on who's the right person to get it done and if I need help then we always reach out and try to get it it's definitely possible to do all those they definitely have free tools for all of these things obviously you can use paint for mockups although I would not suggest it but there are lots of free tools out there just if you look up like prototyping and wireframe you'll find a bunch some are paid for and the paid for ones I think give you a lot more tools and they give you a little bit more robustness but I think everything can really be done even within just the free tools so the question is how do you set reasonable expectations with your clients when they're just hounding you like when is it going to be done or I need it right now and I've heard a I've heard requests before well well can't you just do this isn't that easy and my trick is I've learned that no one has any idea what happens in test I don't know why they think development is easy there's just you go out there and you're good to go but when you're testing that's like a black box for them and so I use I kind of cheat and I'll use test a lot to say well we have to go through a test and we have to push it out and we have to go through these iterations and sometimes I just kind of explain to them what does it take for us to get to the end you know and and really say at the end of the day if they aren't coming around don't budge this is how long it's going to take and it's better for you to set your timelines that you know you can make than to kill yourself trying to make an unreasonable one and I think you know to the point that they had yesterday that's if they need it faster that's the time to say okay which features can go which features do you care less about if you need that timeline then you've got to give up something and that's a good way to kind of work with them and get them to understand that if you really really care about this one feature then you're going to have to either give me more time or you're going to have to give up something else so how do we address a feature that's promptly from a friend end a perspective a dead end what do you mean by that so yeah so in regards to performance or something that the clients may talk may not take into consideration we do try to prototypes help us a lot with that although you may not be able to predict performance issues and so with those we that would be a case where if something has to fundamentally change I would sit down with the user or the client whoever I'm building this for and kind of just I would I mean I would be honest and be like you know here's the problem that we have here's my suggestion for how I think it'll change how we should change things and maybe this is how my timeline's adjusted and just I think open communication is really key people tend to have this feeling like oh I can't tell them the truth I don't want to tell them what's really going on and at the end of the day they feel kind of like you're lying because they don't know what's going on and they don't they just assume that you're making stuff up so if you're clear with them and just sit down with them say this is what we've encountered here's our you know I would always have a solution ready I wouldn't expect them to have it so have a solution ready to offer them and know what what that timeline is going to change so that when you walk into that conversation you're ready to convince them that they're okay with that so the question is how do we kind of really figure out what those timelines are basically and do we set them you know after we're you know a month into the project or do we set them at the beginning how do we gauge that and the way that we do that is we try to break apart the project into chunks at the beginning and so for instance with my sales audience sizing tool we had only one category that we wanted to build and we knew that phase two and three would be adding new categories and improving performance as well as changing some aesthetics so we kind of try to keep our scope of project really small and then determine the timelines for each of those pieces as we hit them so we kind of at the beginning try to say what is the big project how can I break it down into piece one and then we focus the timeline on piece one so the question is how do you deal with the 20% of users who they're usually the most vocal they feel maybe they're some of the bigger accounts they you know they spend more money or they're some of your bigger users or they're just they how do you get them to understand why you're not building their feature I will say when the accounts are bigger sometimes they get their features you know what if you got a lot of money you get what you pay for but when we have we have a lot of users that have been very upset that we didn't create their their niche feature and fortunately for us we're able to point to the feature forum and say hey your features number like 800 if you can get it up to the top 20 we'll build it and so we then you know put it back on them so we're fortunate that we have a feature request but like I did with my sales reps I kind of just talk them through it and say you know look it's your account and that's great but we have a workaround for you so I do we do try to provide a workaround for them to still get the answer they're looking for in some way even if it's not through the product or tool so they can still get some value out of it even though we can't focus our time on that and the other thing I do is I try to make sure that they know which features I am building so that they're aware I'm not building this little thing you care about but here's a bunch of other stuff I think you care about that I am doing for you so they kind of get a picture of not just you said no but what are you doing for them so it still kind of brings them back to that warm fuzzy you're doing something for me you're building something for me awesome thank you guys very much