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 an industry standard set of activities and 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 which 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 huge effect on the success of any project you work on. We are talking about the guys behind the code. The developers whom you never really hear from until you hand them wireframes or a prototype. Usually, this happens mid-project when a prototype has features and functionality requested by your users/product owner, but which is impossible/difficult to deliver for one reason or another.
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. But 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 certain UX decisions, the best we can come up with is…
“Because I am the professional. I know what I’m doing.”
“This is what the users want.”
and don’t forget a fan favorite…
“Jamie said he wanted it there, so I added it.”
When practicing UX architecture/design with no knowledge of what’s going on behind the application, a variety of thing can go wrong. This practice results in scope creep. For example, we begin to discover and our product owner lets us know it is important to know the users address so that the application may display the products that are currently being sold in their area.
We, the UX designers say, ok. We pitch this idea to the users and they are also excited for 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 2 weeks to the project timeline. Now we have to go back to the Product Owner and Project managers and figure out 2 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 a general reason as to why something may be difficult to do; Why you will need to consult with the development team; or why this feature is unattainable. Asking the right questions of the development team before wire-framing but after discovery will allow you to leverage the data you collected during the interviews in a way that will guide your questions and allow developers to object to features that will otherwise increase scope and timeline.
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 key. Asking key 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.
Time that can be spent making sure that the process the user experience architect has laid out is followed to the T. Asking a question as simple as, can we get the location through the API, will save the team the hassle of 4hrs in meetings and having to go back to the PO to explain why it can’t be done.
“As a UX person, you must understand the stakeholder/users, most importantly of all… your development team. The former tell you “reach for the stars” but your developers are the ones building you the rocket ship.”
What we are saying is, don’t stick to just your realm. Learn what your developers are doing. Ask questions. A siloed UX architect is common practice in the field and is usually the reason why we have misunderstandings on requirements, scope creep and PO frustrations. We should do all we can to understand what our team is doing, what resources our client is providing us with and how does that translate into the new process.
Some steps we can take…
Invite your dev team to the discovery process or interviews. Watch YouTube videos, take a development class, or sit down with your fellow developer and learn what an API is. This practice of interviewing our dev team after we have spoken to PO’s and users will help us decipher which features are possible and which aren’t. What we can deliver and what we can’t. Finally, remember that you are on the developer’s team and working towards a common goal. Defend your ideas, but also know when to defend your developer. Sometimes it is way too easy to take a developer’s objection to functionality to heart as if it were an attack on your ideas. It’s not personal, don’t forget you are all on the same side.