Interaction Designer
Every other title is insufficient or exaggerated.
The best way to annoy designers is to tell us something in our design “doesn’t look like it’s aligned properly”. We’ll immediately turn defensive, then double-check your claim, then use one of the alignment tools anyway to be absolutely sure, and then curse you because you were wrong. (And curse you even harder if you were right.)
The next best way to annoy designers is to ask us the following question:
“So what do you do, exactly?”
95% of UI/UX/Product Designers hate answering this question. Don’t get me wrong; we love what we do. The title of “Designer” is something we all cherish, because for most of us, it is what we’ve wanted to be since forever. It’s the prefix to our title — UI, UX, Interaction, Product, Experience, or whatever the people are calling it these days — that we hate explaining.
Especially with the “exactly” appended at the end of “what do you do” — that throws away our standard “I design interfaces for apps and websites” answer, and forces us to explain how we do what we say we do. How does your daily output — the work you deliver at the end of the day — help in the design of “an app or website”? Truth is, we probably hate this question because deep down, most of us hate its honest answer.
We draw.
We put in a lot of effort, sure — we first verbally discuss the whole thing with a bunch of people, then we go to pen and paper, then after a lot of pen and paper (and maybe a pack or two of post-it notes) we find ourselves on flow diagrams and wireframes, and then we move on to vector editing tools to create screens, and we deliberate on them and iterate them until we eventually give up and say “you know what, this looks good.”
And then we export the artboards and say we’ve designed a product.
That’s the part that annoys us; the fact that we know what we’re making is not the real thing. It’s — what one of our favourite tool’s name suggests — a Sketch. A mock. A collection of pretty rectangles and text, signifying an aspiration more than a production. We aren’t building it; we’re just showing what it could look like if someone else did build it.
Our primary output is always an imitation.
But to all designers who feel that way — it’s okay. We’re more architects than builders in that sense; unlike graphic designers, who are actually creating the end product in most cases, we are only creating blueprints for the final product. We’re collating a collection of ideas, decisions, priorities, and assets, and repackaging them into a defined form and function.
Or that’s what we should be doing anyway.
The three audiences of our output
Perhaps the most misleading thing we say and believe is “users first.” It’s not a wrong philosophy to follow (obviously); UI/UX/Product Designers are essentially the only people in the entire product cycle who are actively interested in the target audience, what they want, and how to make it.
The problem with “users first” though is that it is woefully incomplete — and it often misleads us into thinking that the end user is the only audience the product needs to appeal to. Wrong, wrong, wrong.
We are not just designing for the end user. We are always designing for three audiences simultaneously, regardless of what your actual design output is;
1. The Developers
If your developer hates you, it’s your fault. These people are going to build what you claim can exist — learn to love them. Without developers, all you have is an idea with a few mocks to back it up. Without them, neither you nor your other two audiences have anything in the end. You have no product until a developer builds one.
“Production code is a surrogate for decision-making power. It is the only real source of truth; the sum total of all the conversations, all the decisions, all the politics, and all the skilled work that underwent before it…it is everything. Whoever pushes code is building the product. Everyone else is just an influence.”
— Rebekah Cox
The tragedy is, most UI/UX/Product Designers have very little understanding of how production code works (bless the few who are ex-programmers and now working on design). Our mindset, skillset, and community, all focus mostly about the end user and how best to convey the product to them — yet very few people emphasise on the need to convey the product to the developers. If we’re like architects, then why are we always so out of sync with our builders?
To a large extent, the blame lies on the tools we use. Photoshop, Sketch, Figma, they’re all the same — they’re vector design tools. We’re stuck with creating screenshots of the product visuals rather than the product itself. And even if you use what you call “developer handoff” tools — Zeplin, Invision and the likes — you’re still not telling developers what they really want to know.
Those “screenshots” are not everything a developer needs, because they don’t code the way you design; your artboard layers are incompatible with their lines of code. Your “Lorem Ipsum” or “John Hannigan” doesn’t tell them how to fit in something like “Hubert Blaine Wolfeschlegelsteinhausen”. You rarely tell them how to handle errors, empty states, responsiveness, rendering on Internet Explorer (a total bitch in most cases), keyboard shortcuts, loading states, communication with the back-end, or anything to do with how does this go from any one state to another.
These aren’t things you can capture between simple rectangles and text in a PNG format. This is product behaviour, a core component of product design that your primary output often fails to explain, and your documentation often neglects. These are the decisions that make or break digital products. If your final output isn’t answering all the questions developers might have about the product, your final output is incomplete. A blueprint that doesn’t explain everything needed by the construction team is not a blueprint.
The Stakeholders
Say hello to the ones who call the shots. No designer I know has not made fun of their bosses or clients. Secretly, most of us think we’re better than them, because “we’re the ones with the ideas and the focus on the users; they just want their logo bigger, and their marketing agendas pushed. They don’t know design at all.”
Well of course they don’t! They don’t know design, they don’t know development, and they will never care about either one of them more than you do. What they do know about is business. It’s usually much more profitable, much more risky, and much less tolerant of errors. And because they often have their own bosses to report to, they’ll push you hard so that they can deliver what they’ve promised as well.
As Designers, you should learn the language of business in the same way you should learn the language of code. Their Value Proposition needs to become your Product Goals; their Key Performance Indicators need to become your User Analytics metrics; their Differentiated Marketing strategy becomes your A/B testing, and yada yada. Even if you aren’t interested in learning their jargon, you should always know how to sell your design to them in terms they understand best.
Your stakeholders are also never going to be as interested as you in spending days (or weeks) on “Research”, “Define”, “Information Architecture”, or whatever other name you have for that fancy process in which you just sit and debate until you all agree on the same thing. They’re never going to understand why you spent an entire day deciding the colour palette for a website; especially “when you didn’t even design the website yet!”
They work off things they can see and understand; they always want you to deliver something they can actually show to their bosses, investors, clients, or whoever else they’re answerable to. And “we decided on using flat design with a special emphasis on curves, keeping in line with the brand aesthetic” won’t fly. So don’t even try. To appeal to stakeholders, your output needs to be highly visual, realistic, and something anyone will be able to understand.
The End Users
Perhaps I don’t need to elaborate on this as your audience much; there are plenty of other medium articles telling you how to design for the user. Hell, most of have chosen to go with “User” as the first word for our job title; so using user satisfaction as a north star for product design is well-understood in the community.
I will say this though; it is wise to remember that your output as a designer is almost never reaching the end user. Your product, regardless of how you designed it, is received by the end user essentially through your other two audiences; your developer’s code, and your stakeholder’s marketing and acquisitions.
The onus is therefore on you, as the user-first designer, to ensure that the experience they receive is along the lines of what you intended; but much more importantly, your design should account for the fact that post-design changes are inevitable, and what you designed can be easily executed in a much worse manner by people further downstream in the product cycle.
This is especially true for any product with dynamic content or copy; your pretty stock images from Pexels or Unsplash can be ugly jargon-filled graphics in production; the marketing team might go ahead and dump 500 words in a place where you only intended to have 50. Worse, all the data you assumed would come from the back-end in production code never came, and you end up having a significantly unbalanced (or broken) interface in which more than half the things that were supposed to go in never went in.
Of course, you can’t account for everything that can go wrong; but in the endless debates on what’s best for the user, also spare a little time to think about “what’s the worst way this exact design could look down the line?”, and solve for as many of those potential issues as possible. Because the users aren’t getting your version, make sure the version they do get is the best possible one, even if someone somewhere didn’t add something, or added it badly.
Clarity and Fidelity
Now that we’ve cleared up the three audiences for your output, let’s talk a bit about what your output actually is, and how that defines what you are.
User Research, Wireframe, Information Architecture, Flow Diagram, Screen Design, Interactive Prototype — whatever your end deliverable is, it’s supposed to explain a piece of the would-be product. What piece it explains, and how it explains it, determines the prefix to your “Designer” designation. So ask yourself these two questions;
- “How much of the product behaviour does my output explain?”
- “How close does my output look and feel to the real thing?”
The answer to Question 1 is a metric I call Clarity (more specifically, clarity on product behaviour). The more your output explains how the ideal product works, the more clarity it provides. The answer to Question 2 is a metric I call Fidelity. The higher your fidelity, the more your output looks and feels like the real thing.
Using these two metrics of Clarity and Fidelity, you can plot all the product and design deliverables on a chart, and see how they stand;
Based on where your output lies on this chart, you can safely classify yourself into one of the following;
UX Designer (High Clarity, Low Fidelity)
Your primary output (wireframes, flow diagrams, information architecture, content) explains a lot about the future product; it documents behaviour, architecture, flow, and rudimentary layout.
But needless to say, it doesn’t look anything like the real thing. You’ve heard (probably more than once) “this is all fine, but where’s the design?” or worse, “but we knew that already, didn’t we?”
So; good points on explanation of product behaviour, but low points on realism.
UI Designer (Low Clarity, High Fidelity)
Your primary output (static designs), if done well, would look like the real thing; but they’re still images, and that by itself does not explain how the product behaves in any way (responsive, transitional, or motion).
A responsive design explains better how the layout you’ve created will respond to different environments (screens); and if you’ve linked up your screens with the low-fidelity prototyping tools that are now a part of Sketch and Figma, at least you’ve cleared up how to go from one of your screens to another. But you still eventually find yourself as saying “in the real product, this would be a…”
So, good points on realism, but low-to-medium points on product clarity. Your secondary output (assets), however, are production-ready graphics and/or important visual properties for a developer to use in production code.
Interaction Designer (High Clarity, High Fidelity)
Even if your design is purely based off animations (not clickable, or interactive in any way), you’re still providing a very good explanation of how the ideal product behaves (motion and transition), along with actually making it look like the real thing. If the UI Designs are screenshots of the future product, your interactive prototypes might as well be its screen recordings.
And of course, if it is clickable (interactive), responsive, and includes production-ready graphics, your output is as close to the real product as one can get. In fact, with real dynamic data and communication with the backend, your prototype would be indistinguishable from production code.
Which finally brings me around to my main point; doesn’t that mean Interaction Design is the superset of all other forms of digital product design?
UI Designers use high-fidelity screens, which explain the use of graphics, visual hierarchy, layout, and content in the future product; but struggle to explain product behaviour, responsiveness, motion/transition, and flow.
UX Designers use IA maps, wireframes, and documentation to properly explain product content, structure, flow, and behaviour; but struggle to demonstrate its actual use in practice.
Interaction Design, in its purest, highest form, explains everything a product needs on the user end of things; behaviour and layout. Look and feel. It is the fusion of both the UI and the UX of the product.
Interaction Design was always our true end goal. We just lacked the tools to properly throw everything into one deliverable; so we broke it into pieces, and left it to our audiences — the developers and the stakeholders — to join them together. But wireframes don’t explain colours and type; screens don’t explain component states and animations; IA doesn’t explain anything outside of IA; so sooner or later, someone misses your broader picture, and joins the pieces the wrong way.
Fortunately, with advanced tools like InVision Studio and Framer X, we’re closer than we were ever before in providing that one true deliverable to all our audiences; a single output that shows our stakeholders what it would look and feel like in the end, that shows our end users how it should be used, and shows the developers how to build it. A beautiful, interactive prototype that demonstrates everything the product can be. A flawless imitation.
Interaction Design. Because everything else is insufficient or an exaggeration.
