I think that I’ve mentioned here before that I talk to a ton of UX professionals (lucky me) day in and day out. I hear a lot of frustrations, complaints, successes and failures. A good deal of the frustrations that I hear center around people not having the opportunity to either learn or exercise the real tools in our job, including things like personas, task analysis, scenario creation, in short, everything except wireframes. Some people think that they should go independent so that they can own the client work themselves, however most realize they are not yet ready. Either way you look at it, there is one key ingredient that we need in order to lessen our frustrations, learn and exercise the UX methodologies that we want, and just plain be happier in our work. We need to learn the ins and outs of the software development lifecycle.
When I say the software development lifecycle, I don’t just mean the labels on the page of who does what when, I mean the reason why we do the things to begin with. For example QA writes tests cases to ensure all the use cases are properly functioning and the code is ready to release. Developers have local, development, QA and production environments so that each release can be accounted for. The release schedule is every 6 weeks because of infrastructure builds… these types of ins and outs. The problems of not understanding the overall process (not just the UX process) of how our designs come to life are extensive. The main ones that I’m seeing are first, UXers become frustrated when it’s “too late” to use their updated designs, do testing, etc. They are frustrated mostly because they have no idea why something is late and more importantly they don’t know how to question the timeframe. Secondly UXers are frustrated because there is never time or opportunity to learn and/or exercise “real” UX work, just wireframes and interface designs.
In order to lessen these frustrations, become better UXers, and truly understand how our UX processes fits in, we first need to learn what they are fitting in to. We need to talk to our developers, our bosses, our project managers whomever it is that can tell us how the product actually gets built. We need to know release schedules, what is included in a release, when sign off of testing needs to occur…. but more than just the whens we need to know why there is a release schedule, why the timelines are what they are. We need to know what use cases, test cases, other cases do to support the build… and what the build is. Let’s use our tools of task analysis as well as a conceptual analysis to understand these external tools and processes to fit them into an experience flow. Then, we can fill in, move, adjust the gaps of a company’s software development process with our UX tools.
By being confident in what the development lifecycle is, and why it is that way, we can begin to use our UX methodologies to support, change, make better, this lifecycle. We know what our tools are on the UX end, now we need to know how, when and where we can use those tools and what effect they will have. Depending on the context of how the development lifecycle is being used, we can be flexible with what tools we use and when, and of course why we should use them. Knowing these things will prevent us from being taken aback by the “you are too late to use that design” types of discussions, as well as allow us to be creative and flexible in using our “real” toolbox. Without knowing the how & why our outputs are built, we cannot effect them. Learn about software development, become confident in it, then you can let your knowledge guide your career and not the other way around.