Merken

Building Applications Better the First Time

Zitierlink des Filmsegments
Embed Code

Automatisierte Medienanalyse

Beta
Erkannte Entitäten
Sprachtranskript
the world and that the and that it started good morning i'm Jessica Roper I'm a senior software developer at works uh we make software applications for IT prose although this will not have anything to do with that and over the last 5 years of worked on a wide range of products i've had the joy of working directly with our clients working directly with the users in working with a handful of different product managers and over those 5 years and some of those projects have gone better than others and so I wanna talk about and how I've learned to build better applications the 1st time stock is geared a little bit towards early career developers but these attempts I still use and will probably continue to use for the next 20 years the whole
thing is I wanna art and 3 really mean problems and 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 and really making sure they don't discover a fundamental flaw at the end of development instead of at the beginning as some of the pitfalls that I've experienced by not following the steps are delivery deadlines that extended weeks if not months passed what I expected them to be I'm having really poor manager us x 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 and spending time on features that turned when you started actually be at 1 point spent 2 weeks on something put it out there because I thought it was important and then no 1 actually cared at all including the person who requested it and then so there are dozens of other tips and tricks up there but these are the ones that helped me prioritize which features are the most important making sure and iterating through the design process as quickly as possible and really making sure I'm setting expectations at a reasonable level of use these steps in and by myself in groups of 2 or 3 and even in 7 or 8 I think they mostly applied to about all sizes and why I talk about the steps I'm then use an example project that when it not so super wealth and I'll call the cells audience sizing told and then with this tool was geared to do is give our sales associates an idea of how many users could we target for something and so I wanna know how many users in Germany or subscribe to a e-mail that have HP devices this is the kinds of questions were trying to ask and in the past before this tool existed our sales associates would have to figure out what this request was they throw it over the wall to our business and also to then dug into the data and ran SQL queries and then give the results back 48 hours to 72 hours later on so we're talking 3 3 days so they got the results back to really wanted to take that 3 days and turn it into 10 minutes and was our main goal for this particular product yeah the 1st step I have is define the problem clearly have really before you get started you want everyone to make sure the focused on both the same problem as well as the same user and there's a really different uh products they are going to build for instance if you're building a banking application for a banking manager that if you're building a banking application for a banking user the banking manager needs to know everything that's going in and out of the bank and the loans they have out with the state of all those loans are both sides of every transaction but user really only needs to know what is going on with their individual accounts and some kinds of questions that this leads us to ask is can prior knowledge be required and if you think of like CAD like products and not great picture but if you can see here it has a bunch of use of of uh whatever it is this person's creating is 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 OK to expect them to have all this knowledge and not have to build into the tool what's going on and other questions include do other products need to integrate with the tool or do you need to integrate with other products are there and tools that expect to build a user API API is the 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 on the top right you should probably leave it there you don't wanna given new product to users and suddenly have them searching to figure out how to lock out to and my sample projects at the audience sales so the cells audience size and told i 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 3 days is gotta go away and we decided it was OK for a small training session to be given to everyone so they get a 15 minute training session and from me before they actually start using it and mn something else that really helps in this phase especially when meeting with clients is to really write everything down right down the features that you've decided a most important who the user is an especially the timelines you've talked about and I don't personally make uh my managers sign off on what we've written down but when we have followed meetings I always go back and refer to that and constantly make sure that we're all looking at the same time kind of set of expectations the the 2nd of I have is observed the user and if at all possible observing your actually uses in a real environment is so valuable it gives you a huge insight into their day-to-day problems and 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 the getting interrupted about 7 times before they can finish them you know what they're trying to do and if you ask your users what they do it turns out they almost never remember them exactly what they're doing although when we do ask them we would say would you do yesterday rather than water you do generally it helps uncover really focus on what they really did so if you can't see them you can ask them you can least retrofocus what you do on Monday like walk me through your day and end uh a lot of times they leave stuff out so it 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 mixture you ask about them in a lot cases there definitely will be a observe user even interact with them it's either not allowed just not a possibility and there are other ways you can kind of watched them so instead of talking to them directly you can observe their behavior and you can do this through mostly data and so if you are able to use Google Analytics or usage stats and kind of walk through is a point in the process where they start use a feature and then they just don't ever get to the end feature where they get to the 1st page and and never ever come back as an indication that the interest in the feature the interested in the problem you are trying to solve but it wasn't completely what they're looking for is anything they do a lot the really love a certain features maybe that's something that can be expanded on or something that's clearly really critical for them and anything they don't ever do that they page they just never reach for something that clearly don't care about making kind of tell you that features in that area a probably less important to users and then a simple projects and we actually did the wrong thing we observed the wrong user I was automated the BAC of business analysts and so I observed the business analyst ends and by observing the wrong user I ended up making a told that they could use an 1 was very confusing the 1st time we put it in front a cells associate the 1st drafts OK when you know demographic do you want you want the United States you in Germany and they were like I wanna 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 I'm actually like at the end and then go back and read format everything and restructure everything it probably should have taken you know hours if we had designed properly in the beginning observer user but instead we found out at the end and had spent days and doing all that work again the 3rd to by have us focus on the majority and so go from Scottie from Star Trek you can really replace Starfleet captains with users or clients or product managers and in the day they want everything and they want it now and they really want their way but it turns out there really need everything and a lot of times will be off the cost 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 % role we try to focus on the features we care about on problems and things that will work for 80 per cent or more of our users and then so this means that there's a problem that solves a problem that everyone has so in t you really everyone needs help desk that's probably go solve its highest priority and but something that may be only 80 % of our users need some and or something 1 off the users requested which is I need to track a fleet of cars transporting from 1 state to another there's maybe 380 prose that need that so it's cool the needs that but it's not something that's really going to fill an 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 cells are size tool and because I was able to talk to account managers in even the you know VP of sales when they would request things I would always ask you how many other accounts does this apply to and most of the time they'd say 0 you know what it's really just mean maybe this 1 other guy maybe that's not as important so it also helped them to understand why we wouldn't go build their features and again you can't always interact directly with the users maybe you don't have users yet you're trying to figure out what you wanna go build for them and if you don't have any uses 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 maybe there's a problem that's not being sold that you can go solve if you do already have features again going back to look at the features that are most useful 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 many features that no 1 uses those are probably ones that they're not getting value out of a they don't care about and so maybe don't focus on those as much and and cut your losses at that point so the next should I have is prototyping with users is
really tempting to just don't 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 I had uh if we use this prototyping technique which we did not have for the cells audience size until I would've been able to sit down the users and really quickly discover while that flows confusing and spend hours maybe even minutes on it rather than the days that ended up spending at the ends and prototyping is a really important technique for getting early feedback and it helps with designed an and also with uh discovering the flow and really just the general look and feel that your apps can have so and that would be the esthetics and the rule of thumb that we use is after about 5 users we kind of take all the feedback and then iterate and after 5 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 when you can do with anyone it can be your co-workers 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 M. there is a great e-book by you expend it's free and goes in depth on prototyping and on the next things and go over much more in depth so feel free to check it out it was a really good reading yeah the 1st kind of prototype as 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 and the way to use these as you would that can have all these different am views at the bottom you display the first one to user and ask them to do an action and they would tell you and clicking on the arrow on clicking on the middle button and even change the view to represent the next page they would see and if they click on a drop down you can add sticky notes I've actually use just sticky notes and a myriad of them to work through and design iterations to say OK need to add another filter should be on that tab on the side should be a drop down what's go through how that looks and what makes sense for the user and the key thing a focusing on with this kind of prototype is really flow this is not about the color and 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 and so again not the exact spacing between elements or the exact picture that you're going to show the really more about this kind of fundamental flow and this is probably the uh protect its past history on because again you can pull out a practice sticky notes and go at it for about an hour and you can really go through 4 5 in that time the 2nd of prototype is low fidelity high functioning so again it doesn't look a lot like the real thing but now interactivity is there and so the example of these are wire frames we don't care about the actual visual posts really looks like or what a picture really looks like but what I do cares how's the usability if the user is trying to do something can they understand how do the next actions are there any elements on the page that they don't use it all that I really wanted them to use and is there a time when they know actually want take this can't find it the can't figure out how log out for instance and and so in general this should really miniature true events and a really good use case for these is and if you have started working with designers and developers at the same time you can use this to kind of hand out your back in developers they can start working on functionality and cannot use ionization kind of flesh out the way everything else needs to look this is a good way to provide kind of supplemental low-level documentation to get everyone moving really quickly this 3rd 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 and year now focused on exactly what color should be what is the exact spacing should there be a border around the table should be shaded and really all of those and fundamental components and obviously this isn't the time to have like real data real anything in the back end and 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 and so some important what it does it so important how it looks text and there will be there will be a hint of the flow in the mock ups allele kind of focus on each individual page you won't you know show every single action that you can show how the pages are different the the last type of prototype is high fidelity high-functioning is basically is just shy of the real thing it's kind of like an HTML a marked out an 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 solely 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 and I think the best use for this is when you're working with completely outsourced programmers so if you need to hire a contractor someone just not be you can work closely with you can hand this and say this is exactly how I want to look exactly how want to behave in there's no question about what they're going to go do you have to worry about any liberties all take with your design the and the the next thing I have is under promise over deliver so there's a star trek video with the captain and he has an emergency really needs repairs and on the farms got and its but he says how once again take like and in urgent situations titles and it's going to take a weeks we don't have a week since all do it until and that's when the captain says you always multiplied a repair estimates by a factor of 4 and he has he says how else could I keep my reputation is a miracle worker ends I think be like Skype be a miracle worker and you don't want to have every development our plan to just build the products because then when something goes wrong here running around like a maniac until 4 in the morning trying to get it done and that's not ideal situation for anyone the there's an a good rule of thumb that we use in development and my company is to double the dev time we expect plus testing and 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 be a lot of times will be refactoring and complete reworks that maybe you didn't anticipate so if I had um you realize that was possible for the flow to be wrong in my original project I could double that time and we can have and enable to switch that without having to extend our deadlines another thing that happened to us in that that case was Mr. data corruption about 2 days before we were supposed to present this to the entire cell steam and it turns out it took 5 days to put the data in there so obviously we could not do that we had to conclude a rescheduled the entire as sales team for the later weeks just because we had to rerun the data something we can 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 the now you get to the grab a bonus feature something they didn't expect to have that they'd like to have that's now an extra thing and makes you look awesome instead of being late yeah the last thing I have it is create a feedback loop so this is something we do a lot of time at the end of the project but is something you do at the beginning of the project to we actually have an online form where we do have some feature requests so users are able to at request features and then vote the maps were able to easily see which features that cared about the most and how many are at the top there really similar that's maybe a product we could then go create and so that's been really valuable for us to build identify what people really care about and there are other ways to collect this feedback so 1 is gather your own usage data figure out which actions in 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 draw uh discover that they had some confusion and how to use the search tools and be able to address that in all my training from that point forward and I now see when I look at the 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 but I collected and other things you can use our Google Analytics so on Google's a great way they track session times they can actually tell you how far through flow that you got and then so they it can be a good way to kind of measure did people get to the end of the process of the spending time in my tool is 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 understand what it is that they're on having a problem with when it comes to your tool and so in summary there are a lot of the problems that you know could be addressed but the ones that I've covered are you saying expectations and timelines I think making sure that the problem is very clearly defined and it's written down helps everyone have very consistent and expectations and making sure you under promise over deliver it so much better to have an extra feature that has to be 2 weeks late and I guarantee you managers will be much happier that and to identify the highest priority futures features is really all about understanding the user you need to understand what the problems is are that they have and how they're thinking about things would be using and this kind of indicates you what is the problem the majority has what is the best kind of feedback loop that I need and should be data should be forms how can I reach out to them and am I think the main way to very quickly and designs again understanding your users you have a good base of designs you wanna and start with and then just prototyping in any of those levels is really really valuable am 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 depth time in the end times has proved to be externally valuable to us and so this is obviously not an inclusive list of everything but it's 1 that I found most valuable to help improve my timelines so there and consistent accurate and reasonable and help me determine which features of the highest priority so I'm not spending 2 weeks building a feature that no 1 cares about someone actually complained that I built uh 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 however it is and so that they kind of know what to expect and when to expect the does anyone have any questions or other tips and tricks they think I should have shared and so the
question is uh it there's the short answer prototypes is it the same person working on murder nor different people and they can adjust depends as when we do wireframes a lot times we work with our designers a little more closely for that that paper prototyping I I personally do myself and mark-ups uh a kind of depends for mock-ups if the product mostly exists and I'm just tweaking it then I feel pretty comfortable doing that but I do bring my designers a why people in as I need to so and for us we kind of religious focus on who's the right person to get it done and and if I need help then we always reach out try to get it it's definitely possible to do all those they definitely have free tools for all these things and obviously you can use paint for ups although I would matter suggested and but there are lots of free tools out there just to be look up like prototyping in wireframe you'll find a bunch some are paid for and the paid for ones I think give you a lot more than tools and they give you a bit more robustness but I think everything can really be done even within just the free tools and so questions how do you set reasonable expectations of their clients when they're just hounding you what what is it gonna be done I need it right now and I am I heard i've heard request before well will changes to this isn't that easy and on my trick is I've learned that no 1 has he any idea what happens in test I don't know why they think development as easy as you go out there and you're good to go but when you're testing that's like a black box phenomena so I use I kind of cheap and I'll use test a lot to say well we have to go through testing we have to push out we have to go through these iterations and sometimes I just kind of explain to them what is it take for us to get to the end you know and and really say at the end of the day if they want coming around don't budge this is how long it's going to take it's better for you to say your timelines that you know you can make than to kill yourself trying to make an unreasonable 1 on many think you to the point that they had yesterday that's if they need it faster that's the time to say OK which features can go which features you care less about if you need that timeline thing you've gotta give up something and that's a good way to come to work with them and have them understand that if you really really care about this 1 feature then you're gonna have to either give me more time reading to give up something else so how to address a feature that's some promptly from a friend and I expect that perspective the dead end what you mean by that so yes so in regards to performance or something that the me talk may not take into consideration and we do try a prototypes help us a lot with that all they may not be able to predict performance issues and then so it those we that would be a case where if something has to fundamentally change I would sit down with the user the client to around building this for encourages I would buy me be honest a single again 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 timelines adjusted in just thing open communication is really key people and 10 had this feeling like 0 I can't tell them the truth at all until the what's really going on at the end of the day if Elkana like your line 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 a down them say this is what we've encountered here's our you know I would always have a solution ready I would expect them to have it have a solution ready to offer them and know what what the timeline is gonna change so that when you walk in the conversation you're ready to convince them that they're OK with that and so the question is how do
we can't 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 to do we set them at the beginning had we gage that and the way we do that is and we try to break apart the project into chunks at the beginning and so for instance with my cells audience sizing tool we had only 1 category that we wanted to build and we knew the Phase 2 and 3 would be adding new categories and and improving performance as well as changing some esthetic so we kind of try to keep our scope of project really small and then determine the time lines for each of those pieces as we had them some kind of at the beginning to say what is the big project how can I break it down into peace 1 and then we focus the timeline on peace 1
the question is how do you deal with that the 20 per cent of users who there usually the most local they filled maybe there some of the bigger accounts
they say you know they spend more money in the summer bigger users and or they're just stayed high he didn't understand why you're not building a feature and also unaccounted bigger sometimes they get the features you know what you get develop money you get what you pay for and but when we have we have a lot of users that have been very upset that we didn't create their their name in each feature and fortunately for us revel point to feature form say if features number like 800 if you get up to the top 20 will build it and so we then you know put back on them so were fortunate that we have an a feature request but and like I did with my cells after Canada stop them through it and say you know look give it your account and that's great but we have a work-around for you so do we do try to provide a work-around for them to still get the answer they're looking for in some way even if it's not through the product a tool that they can still get some value out of it even 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 where I'm not building this little thing you care about the 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 so kind of brings them back to that 1 fuzzy you're doing something for me you building something for me some figures are much prior the
prior so I have found in
Bit
Subtraktion
Client
Spannweite <Stochastik>
Datenmanagement
Software
Güte der Anpassung
Gebäude <Mathematik>
Kartesische Koordinaten
Projektive Ebene
Softwareentwickler
Biprodukt
Computeranimation
Resultante
Einfügungsdämpfung
Punkt
Prozess <Physik>
Freeware
Gruppenkeim
Impuls
Iteration
NP-hartes Problem
Kartesische Koordinaten
Extrempunkt
Computeranimation
Homepage
Übergang
Eins
Wechselsprung
Client
Datenmanagement
Prozess <Informatik>
Typentheorie
Tropfen
E-Mail
Phasenumwandlung
Prototyping
Softwaretest
App <Programm>
Prozess <Informatik>
Elektronischer Programmführer
Gebäude <Mathematik>
Abfrage
Biprodukt
Bildschirmsymbol
Arithmetisches Mittel
Zusammengesetzte Verteilung
Transaktionsverwaltung
Ausreißer <Statistik>
Funktion <Mathematik>
Menge
Verbandstheorie
Rechter Winkel
Dateiformat
Projektive Ebene
Programmierumgebung
Prototyping
Instantiierung
Lesen <Datenverarbeitung>
Standardabweichung
Aggregatzustand
Fitnessfunktion
Systemidentifikation
Rückkopplung
Wellenpaket
Thumbnail
Wasserdampftafel
Zellularer Automat
Elektronisches Buch
Erwartungswert
Iteration
Fokalpunkt
Stichprobenumfang
Vererbungshierarchie
Luenberger-Beobachter
Biprodukt
Indexberechnung
Softwareentwickler
Hilfesystem
Assoziativgesetz
CAD
Schlussregel
Statistische Analyse
Automatische Handlungsplanung
Datenfluss
Fokalpunkt
Rückkopplung
Flächeninhalt
Polygonnetz
Bit
Umsetzung <Informatik>
Programmiergerät
Prozess <Physik>
Punkt
Freeware
Beschreibungssprache
Blackbox
Iteration
Kartesische Koordinaten
Benutzerfreundlichkeit
Element <Mathematik>
Raum-Zeit
Service provider
Computeranimation
Videokonferenz
Homepage
Übergang
Eins
Client
Softwaretest
Prognoseverfahren
Datenmanagement
Minimum
Tropfen
Figurierte Zahl
Gerade
Einflussgröße
Prototyping
Softwaretest
Lineares Funktional
Statistik
Teilbarkeit
Sichtenkonzept
Benutzerfreundlichkeit
Gebäude <Mathematik>
Güte der Anpassung
Element <Gruppentheorie>
Ideal <Mathematik>
Biprodukt
Teilbarkeit
Ereignishorizont
Konfiguration <Informatik>
Framework <Informatik>
Projektive Ebene
Messprozess
Ultraviolett-Photoelektronenspektroskopie
Beweistheorie
Prototyping
Tabelle <Informatik>
Telekommunikation
Rückkopplung
Subtraktion
Wellenpaket
Thumbnail
Rahmenproblem
Mathematisierung
Gruppenoperation
Automatische Handlungsplanung
Zellularer Automat
Interaktives Fernsehen
Zahlenbereich
Virtuelle Maschine
Erwartungswert
Bildschirmmaske
Perspektive
Reelle Zahl
Front-End <Software>
Fokalpunkt
Datentyp
Zeitrichtung
Zusammenhängender Graph
Softwareentwickler
Inklusion <Mathematik>
Ganze Funktion
Drei
Hilfesystem
Touchscreen
Schätzwert
Fundamentalsatz der Algebra
Raum-Zeit
Schlussregel
Mailing-Liste
Datenfluss
Fokalpunkt
Mapping <Computergraphik>
Rückkopplung
Loop
Touchscreen
Offene Menge
Kantenfärbung
Kategorie <Mathematik>
Zellularer Automat
Vorlesung/Konferenz
Projektive Ebene
Gerade
Phasenumwandlung
Instantiierung
Bildschirmmaske
Punkt
Zellularer Automat
Zahlenbereich
Vorlesung/Konferenz
Biprodukt
Vorlesung/Konferenz
Figurierte Zahl
Computeranimation

Metadaten

Formale Metadaten

Titel Building Applications Better the First Time
Serientitel RailsConf 2016
Teil 69
Anzahl der Teile 89
Autor Roper, Jessica
Lizenz CC-Namensnennung - Weitergabe unter gleichen Bedingungen 3.0 Unported:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben.
DOI 10.5446/31500
Herausgeber Confreaks, LLC
Erscheinungsjahr 2016
Sprache Englisch

Inhaltliche Metadaten

Fachgebiet Informatik
Abstract Feature creep is a common problem in many projects. When you have to take into account customer requests and the ideas of designers and developers, how do you finish all of the features on time? Setting expectations and keeping customers happy can be impossible without the right focus, good communications and proper design. This talk will cover tools and tricks that you can use to prioritize what to complete first and help you iterate through the design process more quickly.

Ähnliche Filme

Loading...