UX Doesn't Stop at Design

Whether we are helping our clients create a new online product or redesigning an existing application or website. Most of our design projects can be broken down into 3 categories.

  1. Conceptualization: Figuring out what it needs to do, why and how.
  2. Design/proof of concept: Creating a hypothesis and proving that it will work
  3. Building it: Meshing the front-end and back-end together and addressing variables, growth, and change

UX Doesn’t Stop at Design

Typically, when you think about UX design, it’s the first two categories that come to mind. It’s true that, if we’ve done our job well, our client gets a user-centered, well-conceived system that will be easy-to-use and seamless to implement.

However, UX work doesn’t stop being relevant to the process once the implementation begins. It is at this stage of the project that we often hear these risky words.

“This is really great work. We’ve got a lot to do in a short time-frame. We think we’ve got this from here; we’ll call you if our team has any questions.”

Translation:

We’re going to try and save some budget. Our technical team “gets” UX. We needed to start coding last week. It will be close enough, and we can always fix it later in another release.

What generally results from this approach is that a digital product that bears little resemblance to the proof of concept that was created in the first 2 phases. Corners were cut to save time and decisions were made to benefit the speed and efficiency of the building process rather than what is best for the end user (your customer) and most strategic for the business long-term.

UX does not end when the implementation starts. It is important and necessary to continue to advocate for the user and the system that was created in order to maximize the time, budget and effort that went into creating it in the first place.

During implementation, there are 2 major things that can occur that will degrade the user experience and often times put you right back to where you started.

Cutting corners to save time and money

In a perfect world, the front end would seamlessly integrate with the back end and we do everything we can to avoid surprises. This is why we collaborate with the implementation team during the early stages of the process—we want to make certain that what we are designing is going to work technically and not cause our client to spend unplanned budget trying to build a solution that won’t work in their environment.

Sometimes an unforeseen technical limitation does surface. The best way to handle this is to first assess the impact on the end user.

Here are 3 questions to ask.

  1. Will this force you to change the design or visual approach?
  2. Does this change impact a process that has been tested already with end users?
  3. Do I understand the risks moving forward with this new approach?

It is wise when things like this surface to take a step back and assess the most strategic way to tackle the problem, rather than looking for the fastest and easiest way. Consulting with a UX expert before proceeding often uncovers a few ways to fix the issue while still advocating maintaining the usability of the experience.

At a minimum, collaborating with the UX team will make you aware of the potential risks of making changes and allow you to formulate a plan to minimize the impact if a problem does occur.

Not having the expertise to address edge cases and future enhancements

When we hand off a design system to our client to implement, we like to say we create a toolbox of patterns, graphics, and functionality that can be used to ensure a consistent and usable experience once it is implemented.

Most of the websites and applications we design are very complex, address many roles and user types and typically contain a lot of functionality, requirements and moving parts. It is nearly impossible to solve for every use case and permutation when the core design system is created.

As an application is being built, edge cases will surface. A successful implementation will use consistent, established patterns to solve for those edge cases. But, what happens when there isn’t an appropriate pattern and a new one needs to be developed?

For example, there is some new functionality available or a new audience to serve. Instead of looking at the design system from the user’s perspective, the team decides to add a new main navigation item because it’s the fastest way to get the content on the site. Pretty soon there are two more main navigation items and the original strategy for the overall navigation system is completely undermined. It was easy and cheap to implement but extremely costly in the long-term.

We generally recommend collaboration with the UX team during the implementation phases of a project to address the challenges that some edge cases will pose. Typically, if they core design system is well planned and executed there are ways to modify existing patterns in order to more effectively address a use case without needing to create completely new ones.

The best way to ensure you create an experience that meets both the needs of your business and what your users want is to allocate time and budget for UX collaboration throughout the implementation process.

If you have a qualified UX expert on staff, make sure you keep them assigned to the project during the implementation to help problem solve and answer questions. If you are working with a consulting firm like us, plan on creating a monthly consulting retainer during the development phase to address edge cases and expand the design system as needed.


If you would like to learn more about how we collaborate with implementation teams from beginning to end to help maintain the integrity of the design system during implementation and beyond, contact us.

Related Insights

Related Insights