There are very few things more disappointing when I'm interviewing someone to fill a UX or UI Design position than that comment.
That one.
That exonerates the designer from anything.
That puts the blame on other people, external teams, parallel universes.
That one, that usually comes up after we look at a prototype or UI animation.
—This interaction you created is really, really great.
—Well, thanks… It's a bummer that the implementation sucks though. The developers weren't able to follow what we told them to do and ended up implementing something really bad, super hard to use.
Breathe.
The art of following through
One quality I always look for as I am interviewing designers is the ability to get their concepts implemented in the final product as envisioned during the design phase. Designers who are able to make that happen share certain underlying design skills:
- Thoroughness in thinking through all use cases and scenarios;
- Feasibility checks while designing, including ability of collaborating with technology teams;
- Ability to influence other teams, including developers and business stakeholders;
As designers, if the final experience wasn't implemented as we envisioned, that's as much our fault as it is anyone else's.
Our role as designers is to create experiences that are easy to use, not mockups that are easy to use.
We are entirely responsible for the products and experiences people use. That's our job; it's in our job title. We are not designers of keynotes and prototypes; we are designers of experiences. Which means we are also responsible for the final product implemented by our teams.
If the final implementation does not look great, one of these things happened along the way:
- We didn't follow through 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, considering the limitations of that platform/code language.
- We did not document the interaction with enough detail, which caused the developers to lose track somewhere along the way.
- We ignored the developers' concerns when they tried to alert us that interaction was too hard to implement.
- We didn't have enough discussions with the tech team about creative workarounds that could fix the 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 realize that interaction was not as conventional as we thought it was. If something is not conventional, it makes it naturally harder for developers to have a reference they can follow.
- We didn't share the ownership of the work with the developers, in a way that would make them feel part of the solution - as opposed to just following what we told them to do.
- We weren't able to convince our product teams (or your clients) to launch a 1.1 version with fixes to that implementation issue.
Generation Dribbble
If designers are responsible for the final product, shouldn't they always design interface solutions that are 1. usable for that audience, 2. feasible for that platform, and 3. viable for that project timeline and budget?
Oh, well.
The disconnect happens because some designers are primarily designing with their portfolio (or Dribbble page) in mind, as opposed to actual users. Urging for likes and claps, rookie designers try so hard to display their UI and animation skills that they end up forgetting about technology limitations, accessibility, and resource constraints.
Not playing too safe
On the other hand, designers who play too safe and only utilize proven design patterns that are easy to implement might be missing the opportunity of making the experience unique, memorable, and fun to use.
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 in your product? What is 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.
Being ready for change
On every project, there will always be changes that external to the designer's influence: new stakeholders joining the team, abrupt changes in release dates, unforeseen platform or technology constraints.
But when I hear that comment in design interviews, I try to dig as deep as possible on the real reasons why "the implementation didn't live up to the brilliance of my designs" - since that tells a lot about a candidate's seniority level. Has the designer faced real, unpredictable changes in that project, or are they just playing the blame game?
Top comments (2)
That's a very interesting take on shared responsibilities, thank you for sharing.
As a developer myself I would say that, while I agree that the designer is responsible, so is the development team. We all work in the same boat, we share responsibilities.
I also think that, in some situations, the conception process can be at fault. The feasibility of the designs should be reviewed by a member/representant of the development team as it can be difficult for designers to stretch their skills so much, especially for beginners. => Responsibilities are shared, let's work together.
In addition to these practical concerns, what I like in your message is the idea that we should always consider what we can do better/change/improve as an individual before looking at someone else's responsibilities.
I feel targeted about the dribbble generation. You're right, we barely keep in mind the accessibility and technology limitations.