Bringing Your Engineering Face to Design
How software engineering can influence your design process
Coming from a background in computer science, my transition into product design has been accompanied by a few questions: How do I best market my background without falling into a front-end developer hybrid role? What skills should I hold onto and expand? Do I have that “eye for design,” or have I been blinded by an undergrad of command line UI?
That’s why I had to listen to Asli Kimya. She came by Tradecraft for a talk on how she applies her background in computer science to her process as a product designer at Twitter. Remembering my need for insight from other programmers-turned-designers inspired me to write this post. I wanted to share her points from the talk, and throw in a few others that I thought could improve anyone’s design process from an engineering perspective.
A note for designers of all backgrounds:
I tried to keep this post free of data structures and Big-O notation. Ultimately, the difference between you and a designer more familiar with the engineering side of things is exposure. I hope this read gives the right exposure to get you started with putting on your engineering face.
Communication
Asli started her talk explaining that she brings engineers into her process as soon as it begins. Just hanging out with her engineering coworkers was a big help. In the earliest of stages, she explained, being friends with engineering allows her to casually run by design decisions and ideas to understand their feasibility before time and effort are really spent on them.
Ensuring that engineering is on board with building your product is essential. Asli exposes herself to their conversations to get the best understanding of her product’s underlying systems and constraints. She also picks up on a lot of jargon doing this, a useful tool for communicating with those building your product. Get engineers on board with your data viz by dropping a mention of a SQL join or two.
Designers are an empathetic bunch, a necessary trait for keeping the user’s needs in mind. So empathizing with engineering in the design process should come just as naturally. The result is a smooth handoff that leaves you and your coding stakeholders happy.
Prototyping
I thought I might put programming behind me as a designer, but it turns out that some easy front-end logic can bring designs so much closer to the finished app — no coding necessary! Asli and her coworkers at Twitter have become familiar working with Origami, Facebook’s free prototyping tool adept at very high fidelity prototypes. Origami uses visual programming rather than raw code, making it much easier to grasp than prototypes created using developer tools. Origami’s interactions and motion design can be fine-tuned to a near replica of the desired outcome. Origami is best limited to small interactions, though.
More recently, Twitter’s designers have been picking up Framer. Though Framer is pricey at $144 a year, it allows for even more possibilities and customization without breaking down as your prototypes get larger. You can even make API calls to use live information. This comes at the cost of utilizing CoffeeScript to define your interactions. CoffeeScript is what you get when you add syntactic sugar to JavaScript, a language that needs it. You don’t need to write too much, though. Framer fills a lot of it in for you. Anything possible with JavaScript, like the web applications you know and love, is possible with Framer.
Both of these programs do have steeper learning curves than simpler tools like InVision and Principle, but they bring you so much closer to the real thing. This means much less costly tinkering to adjust your designs when they hit production, freeing up engineering’s time running your little social experiments. Programmers may feel a bit more comfortable picking up these tools, but anybody should be able to learn Origami without coding experience.
Edge Cases
Programs need to handle all edge cases, so what about your designs?
Asli pointed out that her presentation’s Origami prototypes were a little ideal. For example, button presses immediately played videos. Designers need to be careful not to design for a prototype utilizing static data, and consider that some users are stuck with AT&T’s network. Error states at disconnection and loading states before every video are a part of the experience, but due consideration can make them a little more delightful.
Twitter’s international presence means that Asli also has to consider localisation and her audience. Some of this can be done by accounting for lengthy-word languages like Russian from the beginning. But that’s not all. In English, for example, Periscope displays a capitalized, “Let’s go LIVE”, to ensure that users don’t confuse the video-broadcasting app for a motivational life coach.
Put on your QA engineer hat, and challenge yourself to think up the crazy bits unrelated to the core experience. To remain confident that the final design is at its best, you can do what Twitter does: have office hours with power users that have unmatched familiarity of the products features and flaws. Discovering every corner of an app can take a lot of investment and stumbling around that can be difficult to reproduce at the office, but getting everything right shows so much more polish when engineering reaches those edge cases.
Git
Git is a system for teams to collaboratively build computer files. All of your changes can be tracked, compared, and undone.
If you don’t already know Git, this one’s a doozy. No two ways about it, Git on a production codebase is a challenge because you don’t just need to know Git, you need to pretend to be confident with Git. This takes some practice, and I know just the thing.
I recently ran an 8-person design project utilizing Abstract, an app for Git-like collaboration on Sketch files. Despite my time with Git, I occasionally hesitated pressing Abstract’s big blue button, the primary call-to-action for syncing your work. Still, Abstract is a great first foray into version control and a fantastic tool for design teams. Try it for a project. Once you understand that a press of Big Blue can do no permanent wrong and why, there is a possibility you have a basic conceptual grasp of Git. At the very least, you will bring the same improvement to your design team’s collaboration that Git brings to the 99.9% of software developers who use it.
From there, any designer can try tutorials to learn Git and alleviate the need for JIRA tickets on pixel-perfect UI fixes. Going into code and adjusting it yourself will free up the time engineering spends cursing your perfectionism. Give your Git commits a descriptive message if you want even more mad engineering respect points. One day, you may even come to find yourself understanding Git.
Repetition, Repetition, Repetition
There’s an idea in programming that my professors often talked about but my last-minute all-nighters rarely implemented: functional decomposition.
Programs are a set of steps, and programming often involves using the same steps over and over again. So, programmers put those steps into their own functions they can bring in throughout their code. They even borrow functions from other libraries.
This allows for easy repeatability of tried-and-true solutions. Remind you of anything?
UX/UI designs are a set of elements, and designing often involves using the same elements over and over again. So, designers put those elements into their own symbols they can bring in throughout their design. They even borrow symbols from other libraries.
Hey, thanks repetition! Repeatability saves monumental amounts of time. Create once, use everywhere. Fix once, fix everywhere. This philosophy works so well, other industries are getting on board.
This is why sticker sheets and style guides bring easy uniformity and high efficiency to the design process. Design systems take that one step further, by bringing in a set of rules for components that engineering can use to translate those components into UI elements that formulaically respond to their environment. Seriously, if you want to truly bridge the gap between design and engineering, learning design systems is essential.
All This… Why?
I lied, I have to bring up Big-O notation. But all I’ll say is that there’s a notation for software engineers to communicate the efficiency of code to each other. Engineers are obsessed with efficiency, and for good reason. It frees up a system to make the most of limited resources, like AT&T’s network.
And that’s just it. With efficiency, you can give so much more value to an organization with limited time and resources. Bringing your process closer to the development process makes the hand-off as hands-free as possible, letting engineers do their engineering thing with the efficiency necessary to competitively ship product. Former engineers might relate more to all that, but I think anybody can understand and apply the engineering mindset.
Big thanks to Asli Kimya, Tea Chang, Britta Cheng, and Tradecraft for making this article possible. And thank you for reading!
Don’t forget that you can give as many as 50 claps to a Medium post that changed your life.
