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 prioritise 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 analyst, 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 until they got their results back. So we 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 than 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 like,

CAD-like products, not a 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 always having 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 decided it was okay for 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, you know, 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 do 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? A page they just never reach or something they clearly don't care about? And that 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 reformat 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 Scottie 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, or something one-off that a user's 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 gonna 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's 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 ebook 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 visuals. 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 real data or real anything in the backend,

so you'll see that 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. 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 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 backend is 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 planned

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 and bugs. 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 there'll be refactoring and complete reworks that maybe you didn't anticipate. So if I had 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 go 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 add 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's a great way. They track session times. They can actually tell you how far through a flow that you got. And so 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 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 timeline 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 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 requests before, 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

a test. I don't know why. They think development is easy. 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 kind of cheat and I'll use test a lot to say, well, we have to go through 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 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 front-end perspective, a dead-end? What do you mean by that? So yeah,

so in regards to performance or something that the clients 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, 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, you know, they spend more money or they're some of your bigger users, or they're just, 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've got a lot of money, you get what you pay for. But we have a lot of users that have been very upset that we didn't create their niche feature. And fortunately for us, we're able to point to the feature forum and say, hey, your feature's 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 talked 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. Thank you guys very much.