How to build a UX and development team that really delivers (Part 1/2)

How to build a UX and development team that really delivers (Part 1/2)
Daniel Elizalde

Each company is different, so the process and challenges for integrating a UX team into an Agile development team are unique. In this post, I focus on the people-oriented challenges, which oftentimes arise from designers and developers being completely different. They have different backgrounds, different motivations, and usually different personality types. Creating a cohesive team will depend on your ability to align these very different characters under a single vision and goal. Sounds difficult? Well, it’s not easy, but it’s not rocket science. It just takes work, discipline, and following these tips.

Get to know your team

The first step towards creating a cohesive team is getting your team to trust you. In leadership, trust is the best tool you have, and only if people trust you will they be willing to follow you. Let me say it again. Trust is the most important tool you have.  It trumps everything, even formal authority. Now, with that out of the way, let’s talk about how you build trust.

The easiest path to trust is getting to know your team. I mean, really getting to know them, at a personal level. The book How to make friends and influence people by Dale Carnegie is a masterpiece in this topic. If you are a manager of any sort, you can’t afford to skip it. Now, getting to know people is a big undertaking.  So take it slow and just chip away at it every day. As you make progress, I suggest focusing on these areas:

1. Get to know their professional goals. Why are they doing what they are doing, and where do they want to take their career? Basically, you are probing for their “intrinsic motivators”. Also, ask yourself and ask them: how does working on this product help them achieve their personal and career goals? If they notice you care about their career and their goals (and you mean it), they’ll start to trust you.

2. Understand the different personality styles in your team. We are all different, but one thing is for sure: we tend to trust people that we can communicate well. Therefore, if you adapt your communication style to the various personalities of your team, then you’ll notice how real communication and trust start to build.  A great place to start is by checking out tools like the DISC model. DISC describes the 4 main personality types: Dominant, Influential, Steady, and Conscientious. Each one of us falls into one of these and therefore, we naturally communicate and react in specific ways.  Mastering these techniques will give you a world of advantages. Manager Tools has great information on DISC. Other than understanding the concepts, there are several free online tests you can take. They take 5 minutes. I’m telling you, it is eye-opening, and makes for a great team-building exercise.

Take the time to understand UX

UX is a comprehensive discipline. It’s easy to think we know better because in the past, especially if we have a technical background, we have drafted screens that eventually became the product. Things have changed. Expectations are much higher.  The key to tapping into the power of UX is understanding its value and how it can help you create better products. Otherwise, it’ll be hard to know how it fits into your Agile cycles and the overall big picture. Plain and simple.

My post on UX for Product Managers provides a good introduction. Online you can find many blogs, slides, courses, and even free tutorials. Just search for “what is UX” on YouTube and you’ll see. Believe me, if you spend some time learning about it, you’ll improve your chances of creating a better product by utilizing this new team. Not to mention, you’ll improve the trust of your team by showing you care about and respect their craft.

Standardize the lingo

Once your designers and developers start working together, you’ll find they speak different languages. To make things worse, both camps use some of the same terms to mean different things. I suggest identifying those quickly and setting some ground rules on the terminology the team should adopt moving forward. It will help bring people together and will reduce confusion.


CrossPollinateWhen working with software professionals, sometimes we make some (incorrect) assumptions on their depth of knowledge around the software. Although UX Designers and Developers are both software professionals, their backgrounds couldn’t be more different. In general, Developers are not that familiar with UI principles, navigation frameworks, usability, etc. Likewise, Designers are often not familiar with “how software works” — how it’s created and how the designs they produce become a working product.

Cross-pollinating your teams helps to build stronger teams by educating both sides on the value they provide and the challenges they face. That way, designers can be more in-tune with the effort it takes to implement their designs, and developers can see the value of usability and clean UX for the software they produce.

In my experience, brown bag lunches work great for this. I usually approach people in either team and ask them to present on something they do.  That way, it’s them presenting to each other (not you), which helps reinforce the team bond. Topics can include “software 101 for non-engineers”, “what is UX”, “how a design becomes software”, etc.

Know when to innovate

As Product Managers, your role is to drive the direction to come up with the best possible product. As you convey your vision to your team, put special emphasis on the level of innovation you require. Chances are you’ve worked with Development teams for longer, so you know how to manage scope creep, “technical debt” and seeing how deep the rabbit hole goes.

When you add Design into the mix, you’ll need to work on this again, but from a different perspective. Designers are trained to solve problems and provide the best experience for the user. Your goal here is to leverage the UX team to create as good an experience as possible, and still ship your product on time while meeting business goals. Easier said than done. Remember that innovation is relative and it has to be aligned with your vision. For example, if you are building accounting software, integrating an interface with Google Glass, might be “super cool” and “the best experience on earth”, but it might not be doable or realistic for the target audience. Working with your UX team to set guidelines and direction will be key.

Tying this piece with the cross-pollination really helps. When designers understand the effort required to bring their designs to life, they will be able to weigh the perceived extra benefit for the user against the development effort and cost. For example, do we really need to design a brand new data grid? Do we need a new way to select data or will the good ‘ol drop-down box work? With time, they’ll be able to make great decisions that will augment the product and the ultimate experience while keeping others constraints at bay.

By writing this I’m not suggesting, by any means, that you should stifle your team’s innovation. On the contrary, your UX team should bring a lot of new ideas to the table. The take-away is to acknowledge when true innovation is required or if  using already existing best practices will do the trick. Their time might be better spent on usability testing than finding a new way to reinvent the wheel.

The Bottom Line

These tips will help you with the people-related aspect of integrating a UX team into your Agile practice. The tips are not difficult to implement, but they do take discipline and consistency. In part 2 of this series, I share key ideas for managing the process side of building a solid UX/Development team.  Continue reading…


  1. Suvransu Basu 10 years ago

    Designers maybe able to bridge the gap created within the product by technical debt. But it may not be possible to develop integrate that into development and this may create a possible conflict within the team. How do you handle the same? Is it done through Roadmap and Requirements Prioritization?

    • Daniel Elizalde 10 years ago

      Yes, those situations happen often and your best tool is roadmap and requirements (backlog) prioritization. The Product Managers has the full vision of the product and there might be business or market reasons to prioritize one feature versus another. When a feature is de-prioritized, it’s the PM’s responsibility to ensure that the person/team requesting the feature understands why.That way, they can understand the overall impact of their request and why it’s not best to implement it right now.

      This doesn’t mean that the person/team won’t be disappointed, but if you’ve gained their trust, at least they’ll respect your decision and will be able to back you up.

      Let me know if I answered your question. Thanks for reading.

Leave a reply

Your email address will not be published. Required fields are marked *