As I read Susan Weinshenk’s blog series 7 Tips To Get A Team To Implement Your Recommendation I wondered why we find ourselves struggling to convince a team that we know what’s best, that our ideas are right?  Why do we continue to walk into design reviews praying that our carefully considered work won’t be dismantled? (Insert scene of Don Draper walking into a client pitch.) I hear this all the time “They brought me onboard, so they must understand the value of UX. Why won’t they listen to me?” Heck, I’ve said it myself. Truth is that it’s time for change. Designers must change.

Look at the evolution going on within the development community. Agile methodologies like Scrum have enabled programmers to redefine their relationship with stakeholders. They have created a new way of working that is more effective, creates more business value, increased client satisfaction and last but not least, happier developers. What can we as designers learn from our counterparts to increase our own effectiveness and job satisfaction?

Agile requires people working together on a project to act like a team. Everyone is responsible for the outcome regardless of rank or discipline. It’s an egalitarian structure. (Picture team-building exercises. Trust falls aplenty.) Teams are “self organized” in cross-functional style, which allows everyone to contribute according to their strengths as well as cover gaps instead of restricting themselves to an organizational silo. Collaboration is the name of the game. Agile team members talk to each other A LOT. There is plenty of white-boarding and figuring things out together.

COLLABORATION Designers get twitchy when people throw that word around. It induces flashbacks of design-by-committee and fears of role security. “How can non-designers collaborate on a design when they don’t know what I know about good design?” Well, that would be a valid viewpoint if we were talking about a simple product or art. But commercial software and websites are decidedly neither. They exist in a malleable medium offering a million variations based on past and future decisions. Designing a website without considering the technology is like designing a car interior without considering the mechanics of steering or acceleration.

Developers offer up great design ideas all the time. Designing with them won’t limit your blue-sky thinking. If anything, it has the potential to open your mind to new possibilities that you weren’t aware of. In the world of AJAX, HTML5, CSS3, and countless devices, there are so many interaction possibilities one person can’t possibly consider them all. Working as a team means that you don’t have to strive to know everything on your own. As a UX designer you won’t have to be bogged down with wireframing a basic form layout. You can spend your time on the complex and challenging problems or focus on more creative interfaces.

Collaboration also means less time is required to communicate the design to those building it. Since you worked together to create the design, you are all starting from a position of shared understanding. What will you do with all that extra time? How about finally getting to that usability testing you’ve wanted to do?

Part 2 of Jeff Gothelf’s Smashing Magazine series How to Build an Agile UX Team: Hiring, cautions against bringing a Hero Designer into an agile team. Most of us are used to being Hero Designers. As a matter of fact, most UX Designers aspire to be just that. The person that can walk into the room with the answers, hand development the design blueprints that they unquestioningly build. And the client can attribute their great success solely to your design. It’s a lovely fantasy rooted in the days of print design. Truth is that building software is more complex than that. Developers bring more to the table than the ability to write lines of code. Designers should respect that and use it to the advantage of the product.

It’s time for User Experience to transition from fighting for a seat at the table to being equal contributors. We don’t need to own the design in order to prove our value. In fact, if we let go of this individual ownership in favor of a team approach we will provide more value. Not to mention a more enjoyable way of working. Consider the benefits.

• A less contentious relationship with other disciplines — Instead of the typical finger pointing and antagonism that goes on between designers, developers, business analysts etc., you can move forward together leveraging each other’s strengths.
• Less time spent on revisions that don’t bear fruit – Collaborating closely with other disciplines gives you the opportunity to make quick course corrections rather than waiting until you present polished documentation in a big meeting. I can’t count the number of nights I have stayed up late finishing wireframes only to have the entire solution direction change once the team saw it on paper.
• Less time spent on CYA – Once you’ve experienced the joy of a stakeholder looking to place blame for a product that fell short, you start doing things to make sure you can prove that it wasn’t you who made the mistake. You make sure that you communicate every change through email so that you have a record. Or you document unmet dependencies so that you’re not blamed for missing the deadline. Inboxes all over the world are stuffed with CYA documentation that doesn’t do a thing for morale or the end product.
• Have more time to focus on the difficult problems or be more creative – If you don’t have to spend all that extra time dealing with things that don’t contribute to the end result, you have more time.
• More time to spend with users – Hallelujah!
• Easier to share research findings with your team – When you are in close contact with developers and perhaps even having them participate in gathering research, it is easy to share what you’ve learned.
• See the design as it is being built – No more shocking reveals when you see the finished UI and it doesn’t look the way you had intended. Being in close collaboration means that you see things earlier and more often. You can uncover design elements that aren’t working the way you had hoped or change design decisions that sounded good on paper but have unpredicted effects when put in code.
• Have a bigger influence on the big picture strategy – Informal communication and less hours spent crafting documentation helps to keep you out of the weeds and frees up time.
• A more enjoyable worklife – It may sound like hubris, but it’s not. We have an illusion of control over the products we design. That translates to a lot of frustration when team members are not swayed by our arguments and the design goes in a direction that we don’t recommend. When you see yourself as a contributor, it’s easier to be objective and consider other’s ideas. You also release yourself from the fear that not having control of the design will create an end product that is a bad reflection on your skills as a designer.  Acknowledge and accept the other forces at play. Sure, the product is influenced by you, but there are many things outside of the UX realm of influence, that you could never have complete control over what goes to market.

It’s time that we look inward to solve our frustrations as user experience professionals. Stop setting ourselves apart from our IT colleagues and join them on the same team. There will still be plenty for us to do. And we’ll be able to do it better than ever.