7 Simple Ways To Avoid Being Killed By Your Designer

Tips for developers working with designers

David McGraw

--

I previously wrote about maximizing your team’s efficiency as an iOS Designer and in this article I’d like to flip the coin and talk about things developers should keep in mind when working with a designer on their team.

Design can be a pretty isolated experience. Depending on the priorities of your startup it could live with a single designer for a bulk of the initial growth while new personnel are being added to the team.

How do you avoid making life miserable for that single designer? Let’s go through a few things that are important in my mind, along with a few designers I know.

Establish Consistant Communication

It is critical that communication is consistantly being thrown back and forth between design and engineering. Nobody should ever feel like they can’t speak to each other and neither should ever live in isolation.

Clearly communicate what you need. Is the team attempting to build a new feature and you lack the required design information? Before spending the time and effort building a feature ask the designer for clarification.

Make sure the team’s designer knows where the project stands. Are you providing updated builds? Are you communicating issues you’re discovering that might prevent the designer from doing something?

Don’t Dictate or Micro-Manage Design

This is one of the more contentious aspects of the relationship.

You wouldn’t expect a designer to jump in the code base and begin refactoring the architecture.

This is a collaboration. While it is perfectly acceptable to provide feedback on where the design is going, as an engineer you should avoid dictating exactly how your designer should be designing. Whether it is intentional or not, it is too easy to fall into the trap of believing you are a designer.

Maybe you’re an engineer who studied design or are someone with a solid design sense. That’s great! Your team should be aware of it and the designer can factor that into their process.

The team needs to have trust in the designer. If it doesn’t exist then that should be a signal that the team has the wrong person for the job.

Pay Attention To The Details

There is a reason you have a designer on the team. The team has clearly indicated that design is a critical component by bringing on a designer. Interface development can be a huge timesink when building a project from the ground up so make sure you carve out and a block of time used to execute that vision.

Admittedly, it is unlikely that you’ll knock out every detail so the team needs to prioritize what should be cleared up before the next release happens. Just before you lock down everything in preparation for release ask the team’s designer for a short list of final design tweaks they would like to see completed.

Change Is Not Always Easy

There is a strong desire to demand that design revisions are completed quickly, but it may need more time. Design problems can be complex and require time to explore and test.

The team needs a clear line of communication so everyone is on the same page. Avoid spending time building an area that you think is design complete just because you see the photoshop files. The team, as a whole, needs to decide that a particular area it is complete for the current version.

Once an area of the design is locked in for the current release schedule the team needs to avoid changing what was agreed on. That’s not always easy so you’ll need to weigh the benefit of the updated design revision with the cost.

Find A Design Process That Works

Work with the team’s designer to establish a process that will achieve the best efficiency by reducing rework. Change isn’t cheap for you and experienced designers should be well aware of the impact of their work.

What do you need from design? Do they cut the assets or do you? Should a quick animation be made to display a UX direction? Do you need screenshots? When do you know an area is complete and agree that interface development should begin?

Ask these questions up front and establish a solid process.

Explain What Can’t Be Done And Why

There are certain technical reasons that you will encounter which will make certain design directions infeasible for the immediate future. If you encounter that situation make sure you effectively communicate that to the designer.

Please don’t use that as an excuse for dodging a revision. If it improves your product it would be crazy not to explore it. Some developers have a knee-jerk reaction when they hear the first words uttered from a designer. Simply listen, step back to analyze it and then discuss it with the designer.

Learn Design

While it is not for everybody, if you have any desire, I strongly urge you to read about design so you understand what goes into designing a product. If you want to get in depth, explore theories. Discover rules and usability decisions. Roam places like dribbble.com to discover what designers are doing. Don’t be shy—ask your team’s designer questions.

That’s A Wrap!

Strive to build the best product you can as a team. Care about each member of the team and the role that they are currently undertaking. Be nice, communicate and ship.

Oh, and don’t let your tdesigner kill you.

As always, I’d love to hear from you. Follow me on Twitter, write me and check out what we’re up to at Evomail.

--

--

David McGraw

Grinding my way to the moon. Startups, product and code is what I do and I’m not here to be average. USMC Vet/OIF. Semper Fi