A designer’s guide to engineering lingo
Designing in school vs. designing in real life.
As a new UX designer straight out of school, my portfolio was filled with nicely presented projects (if I may say so myself) that all followed the same linear process. I started with user research, identified personas, crafted pixel-perfect and accessible interaction design, and validated all my decisions by conducting usability testing and additional user research. I felt fairly confident that I had the training I needed to make it as a junior designer in the real world. (Thank you DesignLab!)
After a year in this so-called real world, I’ve come to realize that there was one critical piece missing from my design education — learning how to interface with engineers. True, I did learn about handoff tools, like Zeplin, and I did work with an engineer on two of my projects in school. But the engineering cadence and terminology with a full engineering team was so foreign to me. I was used to talking in personas and pixels, while they were talking about merging and master. I was completely confused and intimidated when I actually had to work with engineers. What?! You mean I can’t just put my designs in Zeplin and then they just make it work without me having to interact with them?!
The fact of the matter is that our designs don’t matter if they never reach human hands.
We can design a perfect product, but if it is never released into the world then we haven’t really accomplished anything. Therefore, the relationship between the designer, the one who takes the power of technology and packages it in a way that regular people can understand, and the engineers, who make the experience actually work, is super important.
When you establish a positive working relationship with your engineers, it’s gold.
No, but seriously, why can’t I just give engineers the designs that I think are best for the user and then ask them to implement those exact designs?
The answer to this question comes down to the fact that “time is money.” Theoretically, it is possible to create any technology, feature or product if we had endless time and resources. We could design in a vacuum and then ask engineers to build what we want.
But the reality is that most companies can’t spend years or even months striving for perfect features. Often, the trick is to both create, or at the very least conceptualize, a North Star design (what we would do in an ideal world with unlimited resources) while also creating the minimum viable product (there are hundreds of great articles on this, so I won’t reinvent the wheel here). Meaning, the question we are always asking ourselves is how quickly can we get usable, functional and even delightful products out into the world? This balancing act often requires design sacrifices or major rethinking. It requires us to ask, “How can we use existing code to create this new experience?” or “How can we remove what isn’t critical to the experience to get this out faster?”
This tension between pixel-perfect design and shipping products out as quickly as possible, is a relationship that can be quite tricky (and oftentimes the Product Manager becomes key in navigating this tension). At the end of the day, we need to work in the space where what we produce is both best for the users and best for the business.
Becoming part of the process
This balance can lead to a constant state of tension, fighting, or feeling like you are constantly at odds with your engineers who are always telling you “no.” Or you could put in the effort to establish a culture of mutual respect and common goals within your team. So…how do you do that? Good question!
It took some time, but the best way I have found to do that is to figure out early on where you fit into each other’s processes. Are you involving the engineers in your planning? You should! Because, again, anything can be built, but the question is at what cost. Do they understand why you’ve made certain design decisions? They should! Because then they will be empowered and motivated to search for solutions that make sense. Do they explain to you why they’ve given specific time and effort estimations for specific features? They should! That way you can decide when to push and where to compromise. Are they involving you in the production of the product? They should! You should be ensuring that the products that are shipped off to humans feel and behave as you intended. By involving each other early and often, there are fewer surprises, fewer conflicts, and honestly…more fun! It is absolutely key to establish a positive working relationship with the engineers on your team in order to create the best user experience for the people you are designing for.
The lingo
A great first start to building this relationship, and easing your stress as you start your first job in the field, is getting to know some of the engineering lingo. The following are terms that I’ve heard over and over again in my work at Nexar, explained by me, a regular person with no technical training (and, as such is simplifying a lot of concepts…I know engineers, I know.) There are variations in how different companies work, but the concepts are similar across the board. Hopefully, this will help you understand how the engineers work and where you, the designer, can fit into it all, both before and during the process.
Source-code repository — A source-code repository is a hosting platform for the code that makes up a product and allows for multiple engineers to work on that code at one time. You may have heard of GitHub, Bitbucket, or Launchpad…these are all source-code repositories. So, let’s say I have a bakery app (because l’ll be honest here, working in a bakery is totally what I would be doing if I wasn’t a product designer) that gives the users the ability to make their orders, customize their orders and pay for their cupcakes all with a simple and delightful user interface. The code that stands behind the app and makes it function is all hosted in a source-code repository, including all of the past versions of the app and the current projects being worked on by various engineers (more on this soon).
Master/Develop — Master (or develop, depending on your company) within the source-code repository is the code which is user-facing and the source of truth for what is currently deployed in the product. Meaning, what the user sees when they enter my bakery app is reflecting the code in master.
Branch — If you imagine master as the trunk of a tree, then branches are literally that, branches that offshoot from the master code. When engineers work on adding or editing code, they do not do so on the master branch itself, but rather create a new branch, which is a copy of the current master code and any changes they add. This ensures that whatever they work on doesn’t affect the master code until it’s gone through tests and has been verified as “good code” with the proper behavior. So, let’s say my product team decides to add a new feature through which users can select the sprinkle types and colors for their cupcakes. The engineer would create a branch off of master and write the code for that new feature on that branch.
Merge — Once the code of a branch has been tested and verified (see PR/CR, testing and QA below), it can be “merged to master,” meaning, added into the code that the user will see inside the product. A new version of the app is created based on this new master code and deployed to production, meaning, sent out into the world for users to use. The users can download the new version of my bakery app from the App Store or Google Play and are now able to choose from hundreds of flavors, colors, and shapes of sprinkles!
On my team at Nexar we have a phrase that goes, “No designer, no merge.” The engineers are required to show the designer the new feature or functionality before it is merged back into master to make sure it lives up to the experience that was designed and specified.
Server — The server, or the back end, is where information is stored and computing actions take place. For my bakery, the entire database of flavors and products, customer emails, order confirmations, delivery tracking information and more is stored on the server. Complex functionalities, like automatically creating a tracking number for each new order, is done on the server as well. The server is the hub of information and action that supports the client.
Client — The client, or the front end, is a product that requests and receives information from the server to display to the end user. Examples of clients are phone apps, web apps and websites. When a user in my bakery app searches for chocolate sprinkles, the app (the client) will request a list of all the chocolate sprinkles from our sprinkle database in the server. The server will spit the list of 45 sprinkles back to the app (the client) and display it beautifully for the user to look through. Note: There are also functionalities that will happen solely on the client, as well, without interaction with the server.
API — An application programming interface (API) tells software components how to interact with one another and defines a protocol around this interaction. An API basically says, “X should go to Y and this is what X means.” For example, in our server each sprinkle type has a name, photo, ID number and the name of the supplier who sells us the sprinkles. When a user searches for chocolate sprinkles in our app (the client), we use an API to communicate from the app to the server that we want to display all the chocolate sprinkles but without the name of the supplier. The API is the set of rules for the “messenger” that delivers the request to the server and then brings only the information back to the client that we want the user to see, namely the list of all the chocolate sprinkles without the name of the supplier.
Unit testing — A unit test is one type of test that engineers use to determine if their code behaves the way it was intended before merging to master. As it sounds, it tests a specific unit or function of the code, not the entire intended flow. The product team in my bakery app specified that once the users choose their cupcake and frosting flavors, they press “next” and get into screen with a searchable list of sprinkles. They can select up to three types of sprinkles. When they press “next,” the users should see a summary of their custom cupcake with their sprinkle choices listed in alphabetical order. A unit test will not test this entire flow, but will ensure, for example, that no matter what sprinkle selections were chosen they are always presented in alphabetical order on the summary screen.
Integration testing — An integration test tests the entire flow of a new experience in a system and how it integrates with another system, like the integration between the client and server. An integration test will ensure that when the user gets to the sprinkle screen, the app (aka, the client) is able to fetch the list of currently available sprinkles from the server so that the user can see it in the app. There are many other types of tests that engineers use in addition to unit and integration tests. These two are just a taste.
PR/CR — After determining that their new code works properly and is ready to be merged to master, the engineer will open a Pull Request (PR) or Code Review (CR). Through the PR, additional engineers in the company will review the code to make sure it is logical, stylistically in line with the company’s codebase and is future proof. Companies and teams have many different protocols for PRs.
QA — During the Quality Assurance (QA) phase, the new version of the product itself is tested to make certain that it behaves according to the specifications of the product team. QA does not look at code itself, but, rather, tests what the users will see. QA is often the last stage in the process before merging code into master.
Engineering sprints — There are so many great articles on sprints and many different sprint methodologies. As a quick overview, a sprint is a limited time period in which defined engineering tasks are accomplished, from planning and writing the code to testing, PRs, QA and, finally, deploying the new features or functions into the product.
Navigating your first design job as part of an interdisciplinary team in the tech world may seem pretty daunting, but being part of a group of multi-faceted and multi-talented professionals is a really rewarding way to bring new products into the world. Armed with the basic engineering lingo and an understanding of how to approach the designer-engineer relationship, all that’s left to say now is…you got this junior designer, you got this!
Thank you to Adi Rosen, Chen Kazaz and Shmuel Lamm for their contributions to this article.
