The Two Most Important Skills for Interaction Designers
They are almost certainly not what you think they are.
Good interaction design depends upon a very long list of skills, from a practical understanding of formal design concepts to the speed and efficiency with which you wield digital design tools and navigate a variety of production environments.
But the two skill(set)s that will determine the success of your design are entirely outside of those areas. When you don’t understand and practice them, you may end up with pixel-perfect design files, but you will end up with products that are far inferior than intended.
You’ll know this has happened to you if your portfolio derives entirely from Figma exports rather than live screen captures.
So what are these three skills? Well, they all are collaborative in nature; they depend more upon how you interact with others than they do upon your thinking alone. And they are required at the three most important stages of your work.
Collaboration with Stakeholders
Whether you are working on an internal product team — where your stakeholders are product managers, marketing and sales leads, and executives — or on client accounts, the way you communicate is critical to everything that happens after.
Stakeholder communication takes three main forms:
- listening
- explaining
- documenting
Stakeholder communication begins non-verbally, with listening. Designers must hone their listening skills. This doesn’t mean simply not talking. Listening must be critical. This means listening for predictable cues to which you, ideally, are trained to respond. Those cues might be aligned with statements of desire — what someone wants something to do, or look or feel like — or expectation — what someone envisions for the future. Listen intently for this kind of information, seek clarification, specificity, and confirmation and write it all down. What your stakeholders want or expect is binding to your next form of communication.
Explaining is best done visually. That means you’ll want some time to digest your stakeholder input and ideate so that your explanations — for what is possible, what is suitable, and what is best — can be aided visually. However you choose to do this, whether in the form of low-fidelity wireframes, high-fidelity mockups, or even interactive prototypes is entirely up to you and your capacity. But whatever you show must be grounded to what you heard before. The job here is in ensuring your stakeholders’ understanding of what can be done, why it will work, why it’s exciting, and why it’s the best means to achieve their goals.
In between explaining documenting is where most designers think the “work” is done. This is the making part — production. And, depending upon how you and your teams work, there may be many cycles of listening, explaining, (production), and documenting.
Documenting, though, is the most overlooked and under-appreciated form of stakeholder communication. Often, the extent of documentation comes down to messages like, “it’s in the Figma file.” We can do better than that. The release-note model employed by developers is a good one for designers to emulate. When a final decision is made, after the listening-to-explaining cycle is through, production-ready files should be turned into a definitive documentation of the decision they represent. An annotated Figma file can work, assuming your stakeholders can navigate the platform. But even better might be a release deck that aligns objectives with visuals.
For as long as the thing you are making exists, these skills must be at work. After you ship something, you listen again, you explain again, you document again. Everything digital is a permanent work in progress.
Collaboration with Developers
I have never liked the phrase “developer hand-off.” It implies that the designer is done — that you’ve done your part and it’s in the developer’s hands now. That should only ever be partially true.
Developers need different kinds of documentation than stakeholders and they rarely get it. This is why the inevitable degradation that cynical designers have come to expect begins before launch, not after. It’s the designer’s job to ensure that developers have three things:
- input
- clarity
- control
Input is the easiest to achieve. Recall our explaining work with stakeholders: when you spend time ideating solutions, it’s important to collaborate with developers so that you don’t end up promising something that either isn’t possible or won’t work the way you assume it will. Give your development counterparts input so that they can provide input.
Clarity is the most overlooked thing that developers need. No matter how detailed your communication and documentation with stakeholders, there are likely to be many details relevant to a developer that are not fully envisioned or written down. When it comes to website design and development, a predictable example of this is the admin experience — how content is structured in a content management system, how it is edited, and the design of the administrative interface. Designers should, when possible, think through these details and document them within their composition files. In Figma for example, heavily annotating frames and workspaces (I like the “DEV NOTE” prefix) with this kind of material is one way to do it. I also like having an additional “Notes” layer that can be turned on and off which visually annotates all kinds of details to layouts, like expected behavior when sizes and amounts vary, relationships between content, functional logic otherwise left up to interpretation, etc.
Finally, acknowledge the control your development counterparts’ expertise warrants. The simplest way to do this is to be clear about where there are flexibilities, guesses, assumptions, and even mistakes and let them fill in the gaps. Often, in “DEV NOTEs”, I will indicate where I am flexible about an interpretation, the relative priority of things, and especially where I have questions or want input. In the best designer/developer relationships, a designer will readily question their own choices and trust a developer to help.
But What About…
Obviously, these two skills are really not as discrete as the title suggests. No “soft” skill is. And it’s also probably quite debatable whether these are really the most important. But in my experience as an interaction designer, every time there has been a meaningful difference between what people thought they were going to get and what they got, it was because of a gap in these two kinds of collaboration — whether communication or documentation — not in a specific person’s executive skillset.
Written by Christopher Butler on
Tagged