Skip to main content
As Graphic Designers, we are often the first bridge between a project’s concepts and its earliest visual assets...

As Graphic Designers, we are often the first bridge between a project’s concepts and its earliest visual assets, and because of this, we must be completely mindful of our client’s goals. The easily overlooked second point is that understanding the capabilities of our own team — and how this translates into time, effort, and resources — is just as essential.

Of course, getting used to this only comes through time and experience itself, but there is one key skill we can cultivate to ensure we’re all on the same page: Active Listening helps us understand what others are thinking, not as words forming sentences, but as concepts building ideas. We can then translate these for everyone involved in the process; the white space you just described to your client is best understood by your team’s Frontend Developer as a 250px padding on top of a new section and as a consistent breathing space for QA to keep an eye on every new page of the App.

That’s where Contextual Translating comes in. Translation entails not only knowing multiple languages but also understanding multiple contexts. This is why learning a thing or two about HTML, CSS, and other coding languages is always a bonus for designers: experience in various environments is key to fully understanding the meaning of what’s being said and implementing the correct translation.

It may appear simple as all you have to do is learn and listen. In practice, it gets tough because you might have to deal with multiple translations at once, and you can end up thinking of solutions midway through instead of actually paying attention to what is being said — but don’t fret! That’s part of learning. Knowing when you’re slipping is one of the steps towards improving your Active Listening skill, too.

Here are a few more tips to get there:

Get a coffee with a friend — then actually listen to them while drinking it.

Talk about any topic with your friend, then make a brief explanation of what they just said using your own words, trying to match their ideas. It doesn’t matter whether you have it right or wrong; what’s important is that you practice listening and rewording, which you’re going to be doing a lot in this scenario.

Talk design to people who don’t do design.

Find ways to describe common design concepts without using niche-based words, such as typography, image ratio, or even pixels. Your average client may not be aware of what these words mean, so you must describe them in a way that they can understand — that, without misleading them. A common example happens when discussing the “size” of an image: you may be referring to its dimensions (height and width), but the receiver could be thinking about the amount of data it takes up on a hard drive (kilobytes, megabytes). In the end, they are both “sizes,” so which one are you referring to? This same idea leads to a third point…

Don’t give ambiguity a chance.

Paraphrasing is not a bad practice. In fact, it is often encouraged in many contexts to welcome expansive writing in order to explain the information being conveyed more thoroughly. (See what I did there?). Talking with clients and teammates is not one of such contexts, though, and relying on terms that are far too open to multiple interpretations can and WILL lead to inexactness, which is the first step down the dooming “redesign tunnel.” Try rehearsing what you’re going to say while paying attention to the words you’re using: is this the right way to describe what you’re trying to explain? Use Google to find meanings and synonyms, and most importantly, don’t place the entire weight of a sentence on a single term; make sure to spend some time describing and contextualizing keywords so that when you use them, there are already many hints of what these words mean, leading to an easier understanding.

Even though correct communication is a crucial component of efficient design, you’d be surprised at how often we struggle to consciously incorporate these fundamentals into our work. These tips act as small shortcuts we can easily keep in mind to ensure we convey the correct message, but there are numerous books out there that explain these and many more concepts in greater detail. There’s no reason not to learn about communication; it’s one of those all-around, super-effective skills that everyone should hone, regardless of their occupation.

Thanks for reading. Please feel free to share and don’t forget to subscribe to our newsletter below!

Whether you are starting out a new project or simply adding features to an existing one, there is a critical step...

Whether you are starting out a new project or simply adding features to an existing one, there is a critical step in the process which usually causes some friction: the “Handoff”. It is considered the action of passing over the current state of the project’s design to the engineering team so the development process can start.

And that couldn’t be any more wrong.

What is commonly seen as a baton pass in a relay race should actually be compared more to a rugby match, where the team runs at the same time, backing up whoever is leading the charge. In this blog post we are considering the term design not only as UI or UX but as an architectural concept where the team designs collaboratively instead of only waiting for the designer’s input. Getting used to this idea of design as a team is not an easy task, here are some tips that can help you implement this format: 

Handoffs? More like Hands-on

Design doesn’t end when development starts, and development shouldn’t start when design is delivered. The Handoff is not the finish line, it is the road. Start collaborating with your team as early as possible, let them know what is on your mind. You can ask your team some of these questions to begin the designer-to-developer flow:

  • Are there any back-end or front-end constraints that I should know of?
  • What are the main points the development team is going to work on first?
  • Is there anything I can share from the start that the team can use as a base?

Speak the same language

Agree on the terms used for the key concepts of the design, by getting team members to acknowledge the established terminology: Components or Widgets, Sliders or Carrousels, Toggles or Switches, etc. This way you’re making sure everyone’s using the same language. Optional: capture this in a document and share it with all the members of the team, this way it will be easier to remember these key concepts using the proper terms.

Check your team’s work – and yours

Most designers will usually agree that their role is to assure the frontend honors the constraints established by the design. You are more than just a supervisor, you should be also willing to constructively critique your own work. Be the first one to notice if what you delivered meets the expectations, even if your client has already approved it. What truly makes a product shine is not how fast and easy the design can be built, but the ability to evolve and adapt to the feedback given by all parties involved. Your first reviewers will be the developers, they are going to share their opinions and most likely will point out flaws that need to be fixed in order to make the design more scalable and re-usable. Take advantage of these opportunities to get closer to the best version of your design.

Prototypes are not almighty

Even if you create a functional prototype, it is hard to visualize the flow between all the parts of a completed design. Only when implementation starts, we can appreciate how things behave when they are connected and sharing data among them. These transactions are part of the design process too and because they are not logical until the components are alive, it is hard to detect those edge-cases that will mostly appear during a QA session. You’ll most likely have to redesign and adapt to these changes – and that’s perfectly fine. Regardless of your experience designing, you’re still human, and you can’t possibly know everything from the go.

Get familiar with your team’s work

You certainly do not need to know what is the difference between Angular and React to create a great UI design, but it will indeed help you and the project to have a better understanding of how much that 3D parallax video slider you’re designing is going to slow development down. Also, you don’t need to ask developers about everything, there is a trick to this: when you are designing something, think of how a user is going to interact with it. Is it easy to explain without moving your hands? If you didn’t immediately think “yes”, ask your nearest front-end buddy about it.

Think easy design

Your development team will be thankful not only for not adding shadows, bezels and opacities to everything, but in the long run, a simple, easy to develop design is going to be easier to polish as well. This reflects in a nicely built interface and a better user experience. Short reminder, if your design can’t be built, it won’t meet any user needs.


While this is not a design guidebook, there are a few last words on the topic that deserve being written: working in a comprehensive environment is not only good for the product you are building, but also healthy for the human beings working on it. We get stressed and tired when things are not clear, so even if it takes longer, even if you’d rather not be bothersome, always take some time to make sure everyone is on the same track regarding your design. Think of your team as part of the great user experience you want to achieve because, as a matter of fact, they are.


The team list

Building a team? We got you. Get the best tips and how-to´s weekly on your inbox.


© 2022 Ideaware Co. With ❤️ from Barranquilla, Colombia.