When Visuals Get Technical: A Better Design Process

Seth Galligan
C2 Team Member Alumni

My nightmare project management scenario sets up something like this:

We're showing homepage design concepts for the first time. After the Discovery and planning work is complete, this is the first glimpse at tangible project work. The pleasantries and small talk exchanged with the client this morning are more spirited than usual as we wait for other stakeholders to join the call. There's excitement for the big reveal.

Our UX designer and I walk through each concept in detail and, to our delight, the feedback is overwhelmingly positive. The client has been teased about what the future state could look like, and now, understandably, they want to know more.

"Hey, Seth. Do you think that this feature can do X, Y, Z thing?"

It seems like a harmless question. We're feeding off the positivity in the virtual conference room and it's intoxicating. We feel as if we've delivered on the client's need. And though I've run dozens of projects on the platform, I'll be the first to admit that it does not necessarily make me an expert.  

"That seems reasonable," I might say. Or, even worse, "definitely!"

Only to find out a short time later, for whatever reason, the feature request can't be supported. Any progress that was made during the meeting is now undone because we didn't tell the truth. We made a promise we couldn't keep that now threatens the client's faith in us, not to mention their schedule and budget. We're just into design with a long way yet to go.

While this is an uncommon outcome, it is a very common scenario. There are just some common questions that are better suited for a technical expert:

  • Will the platform support this design or design feature?
  • Can feature "X" do what I need it to do?
  • Is this enhancement idea worth investigating?
  • How will we support the design from a content production perspective?

We've adjusted our process to include access to technical experts during the user experience and design phase to prevent such a scenario from playing itself out.

At C2, we have a team of adoption specialists we call "experience architects" or "EAs". This team is equal parts "super users" and "business analysts" who have a strong understanding of best practices, technology capabilities, design and content sustainability, and business use cases. One of our EAs, David Korff, discusses in greater detail what it means to be an experience architect.

Experience architects typically become more involved as a project moves into functional specifications and development and again later during client content entry, training, and quality assurance. Including EAs earlier and during the design phase, if for nothing more than an extra set of eyes and ears, is a small adjustment that can make a big difference to the success of a given project.

Insights, Right to Your Inbox.