Introduction

As user experience designers, we have one goal. That goal is to provide our users with an unforgettable experience. How do we do this?

We follow industry-standard procedures in order to gain knowledge about who, why, and how our users will access an application. We research, interpret and apply the knowledge gained during our discovery process in order to meet the user and business needs on every level, delivering an application experience that is comfortable to work with and tailored to the demographic.

Too often, we pay too much attention to the user and product owners, forgetting that there is an entire group that will have a significant effect on the success of any project. We are talking about the guys behind the code. The developers whom the designer never really hear from until the designer hand them wireframes or a prototype. Usually, this happens mid-project when a prototype has features and functionality requested by their users/product owner, but which is impossible/difficult to deliver for one reason or another.

The Core Team

Any user experience designer with industry knowledge and experience knows the makeup of a typical development team; A team that consists of at least one UX architect, one UI designer, 2–4 mid to senior developers, a project manager, product owner, and a business analyst. However, knowing the folks we work with, we continue to make decisions and pass them along as if they are executive orders that are to be followed without question by our team members. When asked why we made individual UX decisions, the best we can come up with is…

“Because I am a professional. I know what I’m doing.” Or, “This is what the users want.” Furthermore, do not forget a fan favorite, “Jamie said he wanted it there, so I added it.”

Understanding Behind the Scenes

When practicing UX architecture/design with no knowledge of what is going on behind the application, a variety of things can go wrong. This practice results in scope creep. For example, we begin to discover, and our product owner lets us know it is vital to know the user’s address so that the application may display the products sold in their area.

Engaging with Developers

We, the UX designers, say, ok. We pitch this idea to the users, and they are also excited about this feature and mock it up, providing the details to the development team. Then our developer calls us into a meeting. He/she then proceeds to tell us that there is no way of knowing where the user is unless we provide a process for collecting the user’s location. Our dev also tells us that this will add about two weeks to the project timeline. Now we have to go back to the Product Owner and Project managers and figure out two things. Is this something that we should proceed with, and if so, how much additional time and money is it going to cost?

It is imperative to stress that a UX professional should always provide an ample reason as to why something may be challenging to do; Why designers need to consult with the development team. Furthermore, why this feature is unattainable and asking the right questions of the development team before wireframing, but after discovery will allow the designer to leverage the data the designer collected during the interviews. They can leverage it in a way that will guide their questions and allow developers to object to features that will otherwise increase scope and timeline.

Proactive Steps

There are steps that we can take in order to avoid being in a situation where we have over-promised functionality but again, for technical or budgetary reasons, are unable to deliver. Communication with our developers is critical. Asking critical questions before implementing user experience solutions for important features will allow us to reduce the number of time developers spend figuring out how to make things work.

The time that can be spent making sure that the process the user experience architect has laid out is followed to the T. Therefore, asking a question as simple as, “Can we get the location through the API?” will save the team the hassle. For example, 4hrs in meetings avoided, because they had to go back to the PO to explain why it cannot be done.

“As a UX person, you must understand the stakeholders/users, most importantly of all… their development team. The former tell them ‘reach for the stars,’ but your developers are the ones building you the rocket ship.”</