UX and Agile
I recently attended a UX meetup that featured a panel discussing whether or not integrating UX designers into the Agile Software Practice works. The discussion was very interesting and got me thinking.
I noticed during the discussion that the panelists made strong distinctions between "developers" and UX designers. While this is common place, it stood out to me distinctly because I am primarily a programmer but I have an interest and background in user experience. I realize the need in larger organizations to hire for specific positions, but I think the skill sets and aptitude for programmers and UX designers overlap a lot.
Both must be very detailed oriented and thorough. UX designers must consider all edge cases and possible motivations in order to shape a users experience. Programmers have to predict all of the little things that can go wrong and account for them to prevent bugs.
Both must be able to place themselves into the shoes of others. UX designers must be able to empathize with various personas to analyze the experience they will have. Programmers always have to empathize with each other in order to make sure that the code they write is understandable and maintainable to others.
Both must be very creative. UX designers must find new and innovative ways to combine, update, and tweak existing UX paradigms to fit new use cases. Programmers must always devise new architectures and patterns to get the task done quicker and make better, more efficient and more stable programs.
I could go on for a while about the similarities. The main difference that I see between UX designers and programmers is that generally UX designers are more people oriented and programmers are more technically oriented. However, UX designers in tech companies are surrounded by technology all the time. They use technology to get their job done making new technologies. Some even learn to program themselves. The definition of a programming language is also becoming fuzzier. UX designers could not design for technology if they didn't know technology. Similarly, programmers use technology on a daily basis. Many are constantly helping friends and family members use technology and learn to appreciate UX design. Programmers are extremely proficient at recognizing patterns and they can see what UX works and what doesn't.
I believe that UX designers would fit much better into the Agile process if we blend our skill sets more. UX designers will still be the experts on user experience and will be the ones innovating on the interface but the programmers can be evaluating the interfaces based on the patterns they see every day. UX designers will still be the ones leading the research but programmers could benefit greatly from seeing some of the research first hand. If we can better integrate our prototyping and development processes, programmers can help designers iterate early on in the development cycle and we can continue to iterate on the UX until the end of development because programmers will be more invested in it.
I hope that one day we can all be considered "developers" and the difference between a UX person and a front-end programmer is no more different than a front-end programmer to a back-end programmer. As a programmer I would love to learn more from UX designers and I would love to teach them more about programing.
We can all benefit from a more fluid and agile UX development process. UX cannot be developed completely before the developers see it because UX is never a static thing. Users, environments, and use cases are all constantly changing. We need to be able to iterate on the usability of the application throughout the entire development process and forever into maintenance of the product. If we do our initial development by doing all of the UX first, it will be much more challenging to iterate on it later.
The best way we can move towards a more cohesive, agile development process including both UX and programming is to stop seeing our roles as so different. UX designers and programmers can both learn skills from each other and support an overall product iteration that includes UX at its core as it should be. What is a product but a user experience?
Follow Me
Connect With Me
Comments
Wonderful post, Andrew. I think you mak very concise points. I'll tell you one thing, the team you describe is the kind I want to be a part of - everyone working toward the same goal (a great product) regardless of skill set. I think you'll find some developers who have more/less appreciation for UX and UXDs who have more/less appreciation for great technology. But if you want to make a great product, I believe you have to have a combined team with functional and beautiful user experience as a common goal. People don't buy a product for it's code (developers should remember this) - but a great experience can't exist without great code (designers should remember that). Its still pretty rare to find one person who is has deep skills in both design and development, but they do exist. And for everybody else, we all need to get behind the goals you describe in your post. BTW - you need to submit this post to a broader audience like UX Magazine or Medium.
Thanks for the comment Dan! I agree, it is rare that anyone will have advanced skills in both UX and programming, but there are certainly some impressive people out there. It will definitely be hard at times to come up with a team who are all dedicated to a great UX but I hope that we as a development community will grow over time and be able to work even better together. I will have to look into submitting this to a broader audience, thanks!
Very interesting to hear your thoughts from a developer's perspective. We do have a lot to learn from each other, and the best teams are truly that: teams that work, think, plan and design software together. Integrating UX designers into dev teams helps eliminate the us vs them dynamic. Yet there are so fewer designers to devs in most teams and indeed software companies. I do think the skillsets are distinct yet also entirely complimentary. For instance, designers should be familiar with what's possible technically but not necessarily write code; and devs likely will not have as strong visual skills and not be as involved with customers. It's really a matter of focus, for me.
Thanks for the feedback Wendy! I think a lot of what you describe depends on the size of the team. As the team gets bigger it becomes more important to find people with more in depth skills in one area that compliments everyone else's to increase the overall skill of the team. Smaller teams can benefit a lot from more generalists that can pick up slack in lots of areas.
I decided a few years ago to concentrate my efforts on UX and more or less let go of my design and front end code skills. That would allow me to partner with other, more talented people on those other aspects. That said, UX is a big, blurry space and certainly bleeds into both design and code. There arises the question "what does it mean to solely concentrate on UX?" To answer that for myself, I chose to embrace and become a T-shaped UXer (someone with a breadth of skills- the horizontal stroke in the "T"- and a depth of skill in a particular discipline- the vertical stroke). I've had the fortune to have been a dedicated designer, front end coder, information architect, etc. over the course of my career. Since UX crosses into all of those areas, the T-shape makes great sense to me. That's not to say that I couldn't or shouldn't continue to hone my HTML/CSS chops for prototyping purposes (for example), but I don't believe it's a must. In the end, I like to work with a group of smart people that cover the range of necessary skill sets with my contribution being one of orchestration among them all while doing a deep dive into "UX work" like strategy, customer interviews, systems modeling, personas, etc. You can effectively blend dedicated specialists with generalists on a team to great effect.
I hadn't heard the T-shaped skill representation before. It is a really cool way to visualize skill goals.
Andrew, Thanks for the post, I believe your main point of integrating the two disciplines more closely is shared by everyone. The goal should always be the delivery of great product; the big question is whether one person can do it all. In theory, this should be the case, but in practice I've only seen it hold true a handful of times. As developers make decisions around code or, for physical product, materials, the user experience is often compromised. And these decisions, while seemingly slight during the early days of a project, can grow into a mess once a product is nearing completion. I had a client last month who choose a light-weight torque screw for the housing on his set-top-box. It was the decision of the industrial designer to use that particular screw (there were 100,000 in stock), and the alternatives would have had an impact on the bottom line (about 1 cent per unit). The result was a set top box that felt flimsy to the user; cheap and too flexible. Users who lifted it up were surprised at the lack of rigidity and often said that it didn't feel 'solid.' My team replaced the in-stock screw with a more solid, slightly longer screw. Users then felt the product was of a higher caliber, describing it as 'solid.' The industrial designer that made the decision to use a shorter, inexpensive screw didn't make a mistake, he made a development decision that would have saved his company 10,000 pennies when manufacturing 10,000 units. But this decision had an impact on the user experience that needed to be corrected before this product hit the shelves. Did the industrial designer ever consider his choice in terms of the user? No. That wasn't his job. His job was to save money and build a product well but at a low cost. His decisions reflected this mindset. Oh, and by the way, this particular industrial designer is a human factors expert who is well regarded in his field. Do we all wish we could consider every business/code/manufacturing decision and still have the best UX possible? Yes. Can we do it in practice? Usually not. That is why it is my opinion that the two remain separate. I describe it to clients with a house-building metaphor: plumbers and carpenters are both able to do much of what the other does, but but you never hire a carpenter when your basement floods. :) Brian
You make a very good point that I hadn't considered. It is definitely important to make sure that you have advocates for all of the important things in any given project. The user is important but so is the business and the bottom line. However, in an Agile team it is the product owner's job to be looking out for the bottom line and hopefully they realize that satisfying the user affects the profitability of a product significantly. I believe the development team itself should always be focused on implementing things the best way possible for the user and the product owner and other people outside the development team should make sure the project is staying on target with the desired market and financial goals.
Good read for UX designers, also what counts more is your mindset and loosing primadonna designer attitudes.
I second the point about no primadonnas! We can all get a little too "in" to our fields at the detriment of a unified team. Whether UX designer or Dev, I think the biggest challenge is to shift the thinking of product and company management to value the user above features/technology. I find it particularly difficult because being user-focused takes creativity - something that scares many away in the business/tech world.