programming, user experience, and more

UX and Agile

This article was published by UX Magazine on July 2, 2013

Earlier this year, I attended a UX meetup that featured a panel discussing whether or not integrating UX designers into the agile software practice works.

I noticed during the discussion that the panelists made strong distinctions between "developers" and UX designers.

While this is commonplace, it stood out to me because I’m primarily working on the development side as 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 that as long as we maintain these distinctions, UX designers will not be able to effectively work within the agile software process. I also think the skill sets and aptitude for programmers and UX designers have significant overlap.

Common Ground One of the principles listed on is that, “Continuous attention to technical excellence and good design enhances agility.” This means that programmers must work on a daily basis with designers. If designers simply hand over designs for the programmers to implement, design considerations are more likely to be left by the wayside as technical challenges arise.

People work much better together when they can find common ground. By recognizing that the similarities between designers and programmers greatly outweigh their differences, we can all learn to work more effectively together on a daily basis.

Attention to Detail Both developers and designers must be very detailed oriented and thorough. UX designers must consider all edge cases and possible motivations in order to shape a user’s experience. Programmers have to predict all of the little things that can go wrong and account for them to prevent bugs.

Empathetic by Nature 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 one another in order to make sure that the code they write is understandable and maintainable by others.

Creative Both must be very creative. UX designers have to 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 tasks completed faster and make better, more efficient, and more stable programs.

Techies One stereotypical difference between UX designers and programmers is that UX designers are more people-oriented and programmers are more technically oriented. However, UX designers in tech companies are technical. They are surrounded by technology all the time. They use technology to get their jobs done and they are often creating technology themselves—some even learn to program.

Similarly, programmers look at technology from a user-centered position. Many are constantly helping friends and family use technology and learn to appreciate UX design. Programmers are extremely proficient at recognizing patterns and they can spot UX that works and UX that doesn't.

Come Together By recognizing these similarities, UX design can move from being a precursor to programming to an integrated part of the development process allowing for better iteration on both the technical aspects and the design.

UX designers will still be the experts on user experience and will be the ones innovating the interface, but they will do it alongside the programmers instead of in their own world. Programmers can be evaluating the interfaces based on the patterns they see every day and technical issues can be addressed earlier. UX designers will still lead the research but programmers will greatly benefit from seeing some of the research first-hand.

Everyone can be on the same page about the importance of each change. Most importantly, by better integrating our prototyping and development processes, programmers can help designers iterate early on in the development cycle and designers can continue to iterate the UX until the end of development because programmers will be more invested in it.

Conclusion 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 greater than a front-end programmer and 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 the usability of the application throughout the entire development process and it cannot stop at the 1.0 release. The usability iteration must continue as long as the product is being maintained. If we do all of the UX first, it will be much more challenging to iterate on it later.

I think that the best way we can move toward a more cohesive, agile development process that includes both UX designers and programmers is to stop seeing our roles as so different. UX designers and programmers can each learn skills from one another and support an overall product iteration that includes UX at its core.

Written by Andrew Wagner


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.

- Dan Larson

about 1 year

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!

- Andrew

about 1 year

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.

- Wendy Constantine

about 1 year

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.

- Andrew

about 1 year

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.

- Mike Rivera

about 1 year

I hadn't heard the T-shaped skill representation before. It is a really cool way to visualize skill goals.

- Andrew

about 1 year

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

- Brian Baker, The First User

about 1 year

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.

- Andrew

about 1 year

Good read for UX designers, also what counts more is your mindset and loosing primadonna designer attitudes.

- Luis

about 1 year

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.

- Dan

about 1 year

Featured Posts
Recent Posts
All Posts
Subscribe To Future Posts

To receive an email each time I publish a post enter your email below.