Engineers build amazing things, but in many cases we’re shielded from the customer experience by layers of product management, UX, and design. Consider the clownfish, who lives inside the protective, poisonous tentacles of the anemone, shielded from the outside world. (Can you tell I just saw Finding Dory?)
Some of us go out of our way to include design in our workflows, but the unlucky among us may never really feel the effects our code changes have on customers, or vice versa, how those customers affect our code changes.
When we’re siloed away from other departments, user experience and design can become an afterthought in the product development process. And thinking of engineering and design as separate entities ultimately affects both: designers can benefit from engineers’ knowledge of constraints, just like engineers can benefit from designers’ insight into customer preferences and usage patterns.
At FullStory we believe the best products are created when every department in a company cares about and strives to perfect the customer experience, and to that end we’re always evolving ways for engineering and design to work together. That’s not to say we’ve perfected the process — there’s still room for improvement — but we try to close that gap between engineering and design a little more with every production cycle.
Start with mocks.
This one might seem obvious, but all too often engineers enter “heads down” mode and bang out entire features on our own, without stopping to get opinions or UX input. When that happens, we expect designers to come in at the very end of development, wave their magic wands and make it look good, as if their job were to put a coat of paint on a newly-built house.
There’s no better way to involve design from the get-go than to start with visual mock-ups of the product or feature. It starts a dialogue between engineering and design. What are the constraints that make the mock-up possible or impossible to execute? Why would customers prefer to do it this way versus another way?
Once you start building the feature, don’t stop trading ideas with your designers. Keeping that dialogue open is the only way to make sure that when you inevitably hit a snag in development, neither you nor the design team veers off the course you set together.
Details matter.
It’s tempting to think of ourselves as mind readers when we’re building out a product. We know what the customers want, or what they think they want, or what we think they think they want, and we’re pretty sure we know what we have to create to help them accomplish that goal.
But the specific details of the interaction matter more than we’d like to think. Designers have a particularly good handle on our customers’ preferences and behaviors, since they either work closely with the UX team or are the UX team. If there’s ever a question of where the button should go, or what order the steps should go in, or when the customer should be presented with a certain option, your designers are the best people to help you frame, research, and understand the problem.
Think like a user, not an engineer.
We have a hard job. We take an idea that has no physical form, write dozens or hundreds of lines of code (along with unit tests and pages upon pages of documentation), and create something that never existed before. Most end users know, on a theoretical level, what it is we do at our jobs, but the finished product in their hands is powered by black magic as far as they’re concerned.
Customers, therefore, have little to no appreciation for how difficult it is to make a piece of software or new feature. But why should they? Just because it was hard to make doesn’t mean it works well or measurably improves our customers’ lives.
Our designer teammates help us put on our user caps. That might mean we find ourselves putting extra work into a feature to make it fall more in line with customer expectations. But it’s always better to build something that people will use, even if it takes more time. Any time spent on a feature customers don’t use (or even worse, hate!) is time wasted.
Don’t be afraid to suggest changes.
This is a great reason to work with designers early and often. We don’t have to be slaves to the designer’s initial mocks — like I said in the first section, starting with mocks is an exercise in communication and compromise. There can and will be unforeseen engineering restraints or sudden strokes of genius that send us ricocheting off in a new direction. But keeping an open dialogue with the design team means that you can suggest changes and updates to the original plan without surprising them at the finish line with a feature they’ve never seen before.
It’s also worthwhile to note that we’re the foil to our designers’ pie-in-the-sky, idealistic aspirations. If their mocks are completely unachievable, we’re the ones who can tell them so, along with the reasons why. Design and engineering are all about iterating, iterating, iterating until you get it right, and working closely is the best way to make sure one department isn’t fading out of touch with the reality of the project.
Do you have the engineering/design dream team?
These are just a few of the ways we work together at FullStory. In the spirit of software development, we’re always iterating, both on our product and our company dynamics. In an upcoming blog post, we’ll talk about how we work cross-departmentally in *themes, not teams *and put all of what we talked about above into practice.
Do you find you work better in cross-departmental teams, or are your disciplines siloed away from one another? Have any tips for improving the design/engineering workflow? Let us know on Twitter @FullStory!
Happy developing!
