Taking Ownership Over How Your Designs Are Implemented: The Underrated Art of Following Through
Fabricio Teixeira / Design Director at Work & Co
If you’re in a role that requires interviewing designers often, you know that these conversations can be inspiring and eye-opening.
There is always that magical moment when a candidate pulls out their computer to share work with you: the anticipation of seeing original designs, fresh thinking, and learning more about the process that led them to the final implementation. Interviews can be a powerful moment to refuel your inspiration as a designer.
But they can also be disappointing at times. That feeling usually relates to a common refrain I hear when candidates feel their work is underwhelming:
“It’s a bummer that the implementation sucks. The developers weren’t able to follow what we told them to do, and ended up implementing something awful, super hard to use.”
The art of following through
One quality I always look for when interviewing designers is the ability to get their concepts implemented in the final product as envisioned during the design phase.
Basically, I want to know: did your ideas actually ship?
I’ve noticed that designers who succeed share certain underlying skills and approaches. These include:
Thoroughness in thinking through all use cases and scenarios
Feasibility checks while designing, including the ability to collaborate with technology teams to work around platform limitations
Ability to influence other teams in their organization, including developers, product managers, and business stakeholders
Too often I’ve seen designers willing to shift accountability — with ease. That’s not okay. The truth is, if the final experience wasn’t implemented as we envisioned, that’s as much our responsibility as it is anyone else’s.
Our role is to create experiences that are smart and easy to use, not mockups that are easy to use. We are not designers of keynotes and prototypes; we are designers of experiences. Which means we are responsible for the final product implemented by our teams.
Fabricio Teixeira working with Technology Director Vanessa Sant Anna. Photography by Sojin Ouh.
10 common reasons for failure
If the final implementation does not look great, one of these things happened along the way:
We didn't follow through on all stages of development and were not available to give feedback and course-correct as the code was being written.
We designed an interaction that wasn't feasible in the first place, based on the capabilities of the platform or framework.
We did not document the interaction with enough detail, resulting in developers losing context along the way.
We ignored developers' concerns when they tried to alert us that interaction would be difficult, not possible, or have serious repercussions on level of effort / maintainability.
We didn't carve out enough time to get in the same room together and have discussions with the tech team about creative workarounds to fix any implementation issues they were seeing — or to simplify the interaction a bit.
We didn't come up with a plan B or C when we realized the implementation was not going to live up to our (and our users') expectations.
We didn't test enough with users to confirm whether the interaction was as conventional as we thought it was. If something is not conventional, it is harder for developers to have a reference they can follow.
We didn't truly share ownership of the work with the developers, making them feel like they should merely follow what we told them to do, instead of having a role in sharing the solution .
We weren't able to anticipate priority shifts for a client partner that could change (and limit) how much time developers were able to put into developing a certain feature.
We weren't able to convince our product teams (or clients) to launch a 1.1 version with fixes to implementation issues.
Looking back at past projects and identifying the underlying reasons for that implementation gap is a self-awareness exercise that can feel overwhelming at times — but it will ultimately help you evolve as a designer. Reflecting on past experiences is the most effective way of preventing the same issues from happening the next time around.
“Looking back at past projects and identifying the underlying reasons for that implementation gap is a self-awareness exercise that can feel overwhelming at times — but it will ultimately help you evolve as a designer. Reflecting on past experiences is the most effective way of preventing the same issues from happening the next time around.”
Generation Dribbble
Great designers feel a deep sense of responsibility for the final product experience. For that reason, throughout the entire design process, these designers are thinking about user interface solutions that are (1) usable for the audience (2) feasible for the platform, and (3) viable for the project timeline and budget. Perfect, right?
But that’s not always the case.
A common reason for this disconnect is because some designers are primarily designing with their portfolio (or Dribbble page) in mind, as opposed to actual users. In seeking out likes and claps, rookie designers try so hard to display their UI and animation skills that they can end up forgetting about technology limitations, accessibility, and resource constraints.
Fabricio Teixeira working with Technology Director Vanessa Sant Anna. Photography by Sojin Ouh.
Playing too safe is a thing, too
On the other hand, designers who veer towards being too conservative and rely on proven design patterns (that tend to be easier to implement) might be missing a unique opportunity to make the experience memorable and fun.
Magic happens when we consider the available resources and are still able to push the team to innovate on key experience moments.
What is the happy path for your product? What’s the main flow, the one that will be utilized by 80% of users, 80% of the time? Defining your key navigation path can really help you focus your efforts on which parts of the experience are worth the investment of love, labor, and time.
Anticipate and embrace change
Not everything is in your control as a designer. But on every project, you can anticipate changes outside of a designer’s domain that in turn can impact the work: new stakeholders joining the team, abrupt changes in release dates, and unforeseen platform or technology constraints.
Still, none of these make that comment in design interviews okay.
As a hiring manager, next time you hear that comment, try to dig as deep as possible into the real reason why “the implementation didn’t live up to the brilliance of my designs.” Not only does it tell you a lot about a candidate’s past experiences; it tells you about their disposition and potential to be a strong team member.
Facing real unpredictable changes in a project and overcoming them will always be a more powerful predictor of success than playing the blame game.
Words by Fabricio Teixeira, a Design Director at Work & Co and Founder of the UX Collective.
Illustration by WNW Member Yifan Wu