Times in the design and development world are changing—fast.

N ever before have developers had so much pressure to build stunning applications for an increasingly educated and demanding user base, and these pressures are often compounded by UI, UX, and product designers all breathing down their necks to execute. 

With sometimes seemingly unrealistic requests for unstable cross-platform animations, 16 CSS type classes and another 328 hexes used, we need to find a happy balance with our developers: a balance between practicality, budget and not making them flip their desks over. Respect them and they will respect you.

Remember, developers with their giant headphones and personalized coffee mugs, are the ones that make our dreams come true.

Without their Java and CSS skills, our visions are just that: flat, static, and lifeless. We need them and they need us, so let’s come up with a secret handshake and some other bonding exercise so we can all get down to creating unforgettable user experiences that make everyone happy.


Don’t worry, be happy.

As a UI/UX Designer, I work closely with a wide array of team members here at Aequilibrium, but none more so than my pal Alex, a senior developer and my collaborator for R&D initiatives.

To make sure we’re successful at what we do, we measure our “Happiness Factor” (HF). The HF dictates the quality and meaning in everything we do as designers. It’s also applicable to developers, and critical in any relationship between designers and the lifeless automatons known as developers (just kidding, don’t hurt me, Alex!).


Measuring the Happiness Factor (HF).

How do we measure our “Happiness Factor” you may ask? Well, take a step back and look at the big picture.

Ask yourself if the project accomplishes theses HF’s:

  • Product Vision Happiness Factor
  • UI/UX Designer Happiness Factor
  • Developer Happiness Factor
  • Usability Happiness Factor
  • Stakeholder Happiness Factor

The power of sprints to increase DHF.

I live (and sometimes die…this is another story though) by the sprint methodology and use it on every project (yes, even when deciding on what to have for dinner that week). Alex and I use the 5-Day Sprint method by Jake Knapp when crushing R&D projects where time is of the essence, so we can accumulate as much data and validation as possible so our CEO doesn’t start thinking we’ve finally lost it, and boots us out. 

One of the fundamental steps in the sprint planning process is the voting. Voting supersedes any “opinionated” arguments that may arise when a designer may have dreams of greatness and a developer can’t agree on a practical, functional UI/UX. Often when I get crazy ideas (stemmed from an addiction of creating products with maximum impact), the voting process combined with collecting feedback from the sprint group settles all. You can’t argue with user feedback and data. The result is an amicable decision that both the designer and the developer had a say in and based on majority vote was validated. Phew, everyone is happy. Well, almost. 😉

Just to be clear, this isn’t an article on the sprint process—there are enough of those all over the internet! Rather, this post is about how it helps a designer get aligned with a developer. You’re welcome.


5 Steps to DHF:


1. Get to know each other.

No, I don’t mean what components or OS you love, but I mean like actual humans. Hang out, play frisbee, drink growlers, watch rom-coms… you know all of that awesome stuff. If you aren’t into that then hey, your loss. Since working with Alex, I’ve gotten to understand his coding capabilities, preferences for frameworks, components and OS strengths and weaknesses. More importantly, I’ve become really good friends with him and have gotten to understand the way his brain works, along with his likes and dislikes. We play frisbee a lot (like a lot), have beers together and chat about space travel and other cool stuff you probably wouldn’t understand. This relationship gets translated into our work and how we work together. I know what’ll probably cause friction and what I don’t even need to make a wireframe for. That is invaluable for product delivery and our “Happiness Factor.” Like I said, start with a secret handshake and go from there.

Remember, in many cases we are designing a product that we may be using in the future so everyone’s opinion matters…

QUICK TIP: Find a common interest (no this isn’t a relationship building exercise post) that you’re both pumped about and get outside. Whether it’s during work or after, I’ll take a quick break with Alex, Lorenzo and whoever else wants to, and go hurdle the frisbee at lightning speeds and unheard of distances at the park across the office.




2. Get close, huddle.

Outside of team prep meetings and the forever present JIRA task board, make sure you’re in sync with your dev peeps. Alex and I will often have our own scrums and mini-huddles to step outside the big picture scope and sort out little details, which if not dealt with, add up and come back to bite you later. These huddles often consist of a 5-10 minute discussion on components—we’ll discuss what we can use from another project to accelerate the overall build and more importantly, Alex will get a clear understanding of my expectations and where my head’s at in regards to achieving the product and UX goals. This can then be translated to the rest of the dev team.

Don’t overcomplicate a design component… if a component isn’t straightforward, don’t leave it up to the developer to figure it out. Provide the context behind it, why it’s needed, and where it goes clearly.

QUICK TIP: Use a quick huddle to sort out dilemmas in your decision-making process. Stumped on the UI flow? Easy, often your developer partner (or team) can be the equalizer and help snap you back on track by offering another set of eyes on the problem.



3. Get down with the lingo.

I’m not saying to learn coding language overnight, but get a basic understanding of what resonates with your team to deliver the UI request—Angular, Ionic, Firebase, CSS classes and even basic terminology like the difference between a toggle and a tab reveal component. When you both “talk the talk” you both understand each other, which quickens the product development cycle and clarifies goals or blockers. A developer should know the difference between a customer scenario and scenario mapping, and a designer should know the difference between CSS styling and Javascript language. Less time wasted on meetings and more time pushing stacks and pixels.

It’s really about making the design asset handoff as seamless as possible. It can be as simple as isolating a grouped bunch of layers for a particular component via that show and hide “eye” button so that we’re in business.

QUICK TIP:  Spend a few minutes before kicking off a sprint project to familiarize yourself with the project type. Mobile, desktop or Apple watch, a developer will help you learn the project language faster than you can Google it, so ask.




4. Get organized.

Increase your developers’ “Happiness Factor” with organized files. Clearly define a UI component and it’s purpose, and organize your layers and files like they organize their dev stacks. Utilize amazing tools like inVision and Sketch to change your designs into actual working prototypes that can easily articulate a function. I love Photoshop CC to build easily accessible element libraries and multi-screen artboards. Another great tip I can pass along is to be consistent with your designs: pick a button style, typestyle, whatever, and apply it to every screen in the same manner. Organization, neatness, and consistency drive happiness scores through the roof.

Designers can make developer life easier by being consistent in their layout and styling choices… while maintaining the same quality of work.

QUICK TIP: Pick a prototyping tool and educate your dev team with it. You can thank me later. A great prototyping platform such as inVision allows you to not only show UI functions and flows with clickable hotspots, but it’s also a very capable resource for your asset files, screen sharing, conversation meetings, and demos to clients.




5. Get feedback.

If you’re using a sprint process, most of this is covered. However, for normal product development, after the team sync, don’t go run and hide with your 87 assigned tasks in that back closet (with some insanely obscure french house Daft Punk mix blasting through your Bang and Olufsen limited edition headphones). That is the worst thing you can do, and is often the sign of a highly opinionated designer that isn’t flexible or adaptive to constructive criticism by their peers. Whenever I’m unsure about the UI function or user flow, I have learned the best thing to do is to ask your team. They will have a wealth of UI and interaction knowledge and will often look at the problem practically. Asking your teammates for their opinion has a greater effect (and in my opinion an invaluable one), a sense of ownership of product development and also helping a peer out with a problem. This builds trust and solves a problem at the same time. Win-win.

…a willingness to change the design when there exists a technical difficulty, without throwing a hissy fit, jumping through a window, and running down the middle of the street screaming, “NO ONE UNDERSTANDS ME!”

QUICK TIP: If you can’t solve a problem quickly, ask for help. I assign a timer to a problem and if I can’t solve it within that timeframe, I ask a developer associated with that function for their feedback. If you’re still not convinced or can’t come up with a simple solution, perhaps the function is incorrect and you need to revisit it’s purpose. You can also ask another person for a third set of eyes, and have a small brainstorming session with a piece of paper and a timer. Celebrate with a secret handshake (or a game of frisbee).



How do you score?

Looking back at these 5 tips, how do you think you did?

Put a rating on each from 1-5, 5 being amazing. Score yourself honestly, then *gulp*, see how honest you were and ask your developer team the same questions and compare. Good luck!

  1. How well do I know the dev team?
  2. How well do I communicate?
  3. How much coding language do I know?
  4. How organized are my files and assets?
  5. How often do I ask for help?


Have your developer’s back and they will have yours.

At the end of the day, it’s about owning your product vision, confidently stating your case when issues arise and being adaptable to feedback. Remember, developers bring your vision to life, make it real and offer insight. Without them, all you have is a bunch of beautiful pixels that do nothing. Respect them and in turn, they’ll respect you, your outlandish visions and insane, unstable animation requests.

Take a look at your process and relationship with your developer and see where you can make it more impactful, meaningful, and cohesive—just like your designs.

Now, go out and play a game of frisbee. 

Posted by:Matthew

I am a Product Designer with a passion for user experiences and the perfect atmospheric conditions for frisbee.