March 28, 2019
The landscape has changed; technology moves extremely fast. With powerful tools now are at our fingertips, a small team is capable of more than ever before. There are certain attributes needed to make this powerful duo perform. There should be talent, creativity, passion and foresight, and then theoretically – magic happens. But the designer/engineer relationship can be a struggle. One filled with tension, ego, and misunderstanding.
A designer uses creativity to invent something that doesn’t yet exist, bringing something beautiful into the world. An engineer does exactly the same thing, but instead of using a visual, right-brained vocabulary, they use the left-brained language of math and logic. How do you bridge this gap? How do you walk across that chunk of fatty tissue between the two lobes?
As a creative, I’ve worked closely with engineers for years. Sometimes we were creating original products like some of the first iPhone Apps. Sometimes I was a hired gun designer on an engineering team. Now, I lead creative teams including internal designers, vendors, and engineers. Each of those scenarios has a method to the madness, but below are some overall tips I’ve learned to make the designer/engineer relationship as dynamic (design term) and robust (engineering term) as it can be.
Talented designers aren’t trying to make something look pretty, cool or custom for the sake of it. Just like good engineers aren’t saying something can’t be done because it never has been done. One does not exist to make the other’s work harder.
You can gain respect and advance collaboration by living in each others world a bit, or a lot. By treating your team member like a client you can begin to understand his/her challenges and approach. A talented designer that understands engineering principles, the way he/she might approach a problem, and the reasons why, will profoundly benefit the team. Understanding engineering resourcing issues, how long a development task should take, or what work is even possible is incredibly helpful in a creative environment. The same goes for an engineer that understands design principles.
You don’t always have control over the team that’s assembled. In some cases, you might need to educate people on why the work you do is imperative, as well as the reasons for the decisions you make. Put in the time. This should be easy. There are strong reasoning, research, and design principles that go into any good designer’s work, while strong logic, analysis, architecture, and best practices go into any good engineer’s.
Education also happens organically when someone is being challenged. The work is better when the group is smarter. It’s important to ask constructive questions, to ask “why”. Listen. Teach. Question. Share in
Designers and engineers think differently. It sounds obvious, but it’s important to remember this while trying to get your ideas across. How does their thinking differ?
A designer’s questions on user interactions
How do we get the user to engage and how do we tap into their emotions?
An engineer’s questions on user interactions
How does the app react to human input and how does it communicate back?
Designers and engineers each have a distinct focus. In this example, one focuses on human engagement, one focuses on functionality. Understanding where the focus lies is a helpful jumping off point. From there, talk less about deliverables and more about project goals. It’s easy to get into the weeds if you’re trying to take on someone else’s focus. A designer may not totally understand the engineer’s details of a project’s logic, and that’s okay. Because the guiding light should be the project’s goals.
There’s a tangible mindset shift when the team thinks first in goals like ‘encourage more engagement through freedom of expression’ vs. a tactic like ‘build/design a home screen’. Then individually, how can everyone deliver on that?
Designers make engineers look good. Engineers make designers look good. In our industry, substance is not more important than how something looks. Both are important and need to be treated that way. Design dictates how a user feels while using a product. This feeling, whether subconscious or not, helps a user decide whether it’s your product they use or someone else’s.
I was talking with an engineer once about his frustration with not having a designer on his team to make the super-awesome product he was working on, look indeed, super-awesome. It’s true, people are visual. In order to believe and trust in a product it has to look and feel as good as it works. Getting people to rally around a product takes powerful functionality, meaningful features, and design that speaks to them.
Take, for instance, the Apple App Store when it opened in 2008. The first apps to hit the store were built by forward thinking engineers. Because some of these engineers were independent or a small team, design was left on the curb. They ended up making fantastic apps that looked less than fantastic. People didn’t know what to expect in the beginning, but they quickly became accustomed to the superior design aesthetic that the iPhone epitomizes. This opened up the door for someone to do the exact same fantastic app, but one that was well designed and won the hearts of the competition’s users. A prime example is the array of weather and news apps that have the same essential functionality but riff over and over in design and UX.
Stop thinking in terms of a design ‘hand-off’ that happens once final design is approved and engineering starts. Design and engineering start at the same time; from strategy through the build. It’s helpful to create space for designers to think in code and engineers to think in design. Engineers can moodboard and designers can prototype. The work will be better for it.
Also forget about ‘final design’. We need overarching guidelines to hit deadlines, but we need to allow room for flexibility and change. You can’t always see the forest for the trees. Don’t allow early decisions to bind a project up. Try hard to kill the mindset that what’s being built today will never change. Real-time user testing will inform and cause needed iteration.
Style guides; interaction guides; vector assets; animation prototypes: These items take up a lot of a designers’ time to produce. But they’re worth it.
The more designers do to inform an engineer, the better the outcome will be. Yes, the idea is to work closely during the whole process, but so much of that time is verbal communication through scrums, brainstorms, etc. When the details and design decisions are only explained verbally, it leaves room for a large gap in understanding. This could lead to let down and frustration on both sides. Reference is a powerful tool to keep the common vision clear.
Lay this groundwork, and with the right people, you will see the work and individuals advance. The right people is key. This kind of collaboration is not for everyone. Not everyone has the ability or desire to venture outside their cozy silo. At Valtech we cultivate an environment of cross-pollination and seek out people who thrive on this kind of collaboration. These types of people tend to gravitate toward each other.
