A few years ago, I imagined this concept of the “restaurant model of design”. In this model, the designers are like the chefs who remain in their kitchen and cook up awesome food; and the account managers and project managers are like the server who would be the primary communicator and would go and take orders from the customers. They would be the primary point of contact and they would do all the talking and heavy lifting. Designers could occasionally go out and talk to customers if needed, but otherwise, this would be a seamlessly autonomous process that would just work.

This is bullshit, and it just will not work.

As a designer, it is in your primary job description that you communicate. Unlike some developers (not generalizing here), you cannot afford to complete a design work by sitting in the corner desk in isolation and moving your JIRA tickets to done. You communicate with the clients and stakeholders in every step of the design process life cycle. Each step would present you with unique challenges and you would use communication as the key to clear each hurdle and move to the next step. This is like a game, and your weapon of choice is your ability to communicate and articulate the facts.

---

Discovery and design kickoff

In this phase, as a designer, it is your job to conduct and choreograph these client kick-off meetings. In these meetings, you will talk to the clients and extract information on what problems they’re having. You will ask questions, framed in such a way that maximizes the amount of information we can get from them, ranging from their company to their employees’ everyday tasks. This in turn, will open up our knowledge breadth and we will be able to take more informed decisions on the client’s behalf.

If you don’t speak, you will never know what they need. Questions that are not framed in a correct way will either not yield expected understanding or will mislead you and your team. So it’s critical you’re articulate about speaking to the client. I remember once one of my friends telling the client: “Please bear with me through this process. I am going to be asking a lot of questions and irritate you. Please don’t be irritated.”

Nudge them, play with your words, become from friendly, talk like you know this person and are having a casual talk. This will, in turn help the client open up more and spill out more info. Don’t forget to paraphrase and repeat for confirmation.

SAY: How does your employee manage their files in their everyday workflow?

DON’T SAY: Will it help if I create an uploader to upload all your employees’ files to the cloud?

User testing and prototyping

Okay, our super-duper project idea is now done. We have also quickly sketched out some wireframes and we’re ready to go to the users and ask them to test it our for us. How will we ask? We will inform them what we have built, how it works and what’s expected of them. With the right context and expectations in place, your users will be onboarded to test out your hypotheses (in the form of prototypes) and let you know if it solves their problem or not.

This phase literally kicks off with your meet and greet with the users. Now based on structured or unstructured tests, you will begin by asking users some questions. Put the context of test scenario in place and tell them what they need to do — without complicating it, or intimidating them.

SAY: Please open the file manager and upload a excel file for me.

DON’T SAY: Please click the blue upload button and click next..next.. to check out the document upload feature.

Developer handoff

Developers need to be told. When I was building a new bathroom in my house, because my mason and plumber did not talk to each other, we had to dismantle an entire tiled wall in my bathroom because the pipes were not laid out correctly. Similarly, not speaking to the developers could be a fatal or an expensive mistake. Designers and devs are bff’s and they need to be on the same page, down to the same line in that page.

The first and foremost step of a developer handoff is a demo meeting. In this meeting you will give a walkthrough of the user flows to them, showing every nook and crannies of your design. You will show them how the components have been specified. You will show them the color and style libraries and what it means to them. You will use design tokens if need be.

Developer handoff also is not a one-event thing. You will need to be available and help developers navigate the design patterns and user flows as these things take time. But always remember to check in, be proactive and ask to help wherever needed. Developers love helpful designers. Be one.

SAY: Here is the link to Figma file. Please use the Inspector mode to extract anything you need. I have correctly tokenized the styles, connected all the user flows. All the components and assets are correctly labeled and conform to specs. Let me know if you have any questions.

DON’T SAY: Take it and go.

Usability testing

Alright, it’s showtime! Time to go back to the users and test out the system that you and your bff have just finished building. This step too requires some aggressive talkativeness. You need to be able to (like in user testing phase) help users understand the context and scope of what you want them to do.

First off, start by asking them some basic questions like their age, ability and frequency to use apps and also involve in some small talk to get them in the right form. Then in the next step, go ahead and ask them to use the app. Create a safe space for them to test it out. Engage frequently to check in but don’t be too indulged in the process. While they use or after they’ve used, indulge in conversations like things they like versus didn’t like, if anything got in their way to complete the action, their reasoning to do something in a certain way and so on.

Be nice, be benevolent — listen to what your users say. This is a tremendously valuable skill for a designer to be able to listen to innate understanding of your users. None of this is going to be possible if you don’t engage in a conversation during usability test.

SAY: What do you think about this file management feature?

DON’T SAY: Do you think this file management feature will make it easier for you?

Design upselling

This is like an annex to the actual design process but it’s equally important. A lot of the times, we as designers just do the bare minimum to complete the project and not go beyond it. When you go past your current assignment, more opportunities await beyond the horizon.

Let’s say you have built the file management app. What other things can we add so that it becomes more valuable to the client? How about a landing page? How about a tutorial video on how to use the app? See, there are so many more things that can be done in addition to the design service you provided. It’s always a good idea to let the clients know that you can provide these services too. There is a good chance that if they like your delivery, they will want to get involved in building out these supporting collaterals. Just let them know.

SAY: Hey, just letting you know that we can help you build more tools to sell your software. Please feel free to get in touch and we can discuss your requirements.

DON’T SAY: Take it and go. Sayonara.

---

All in all, design is a very verbose business. There is no place for people of few words here. You need to communicate day in day out to make sure you’re delivering what you need to. Design does not happen in isolation — it never has and it never will. Designers will always find people surrounding them, from clients to account managers to developers to QA’s. So be well versed, be well spoken — be a great communicator that your job demands yo to be.

---

This content was originally published in the design swap podcast. You can listen to more episodes by subscribing to my podcast in Apple Podcasts, Google Podcasts or Spotify.