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.
Thanks for writing this! As a UXer who got her undergrad degree in computer engineering focusing on software, this is refreshing to hear. I hate it when I hear UX designers talk about programmers like they’re ruining everything.nnProgrammers aren’t ruining everything, they’re making everything. Without their code, you don’t have much to show your client other than a bunch of plans. The programmers should be considered stakeholders just as much as the business team, design team, etc. Understanding the technical constraints earlier in the design process can only be a good thing.
[…] UX… It’s Time to Learn Software Development […]
This is one of those posts that I appreciate, but can hardly believe is needed. I’ve long taken SDLC steps and functions into account, to the point of meeting with dev and test teams during design. I am surprised that enough designers don’t that we need this helpful post to enlighten them.nnI’m glad you also mentioned the need to use the knowledge to be adaptable to what development teams need. Many designers are confronted with requests for contribution to projects in process and can respond with nothing better than quoting the standard design process. That doesn’t really fly.
Yes, it seems odd at first that designers don’t always see the connection with what they do and how that fits in to the greater process of building software. I’m wondering if there is also a lack of this knowledge in the schools that designers are learning at. More fuel to add to the fire :-). Thanks for reading Phillip!
Very good post. I would actually argue that if you don’t immerse yourself in these things and come to a thorough understanding of them (like you mention, understanding the WHY, not the WHAT), then you haven’t yet become a member of the development team. And unless you are viewed as a member of the team, living the struggles with everyone else, then there’s any number of problems you will constantly have to confront which you would be unequipped to solve.nnIMO, UX/Design can not be an entity which exists separately from the development team. nnAlso, your focus on the WHY rather than just understanding the WHAT is a great point that’s often easy to forget. If you know the “why” behind a process, tool, etc, then you can have gaps in your understanding of the what/how and still be effective. “Why” trumps everything. The example of the cargo cults comes to mind as a good illustration of how skipping the why can have a profoundly negative impact on your effectiveness. 🙂 I personally believe this is a philosophy that has served me well in every facet of life, not just working on software teams.
Thanks Alan! Yes the why is the most important thing and always hard to remember, however, now to us, the most obvious thing to question. Thanks for your insightful points!