In every line of code, engineers make code architecture and implementation design decisions about the products they build. In summation, these micro-decisions set the functionality and ease of future development of the product. Every engineer should play a role in product decisions.
When the engineer is a part of the product dialogue and decision making process, the engineer gets to be part of asking the bigger questions of why are they building what they are building and who are they building it for, which it saves time down the road and often makes the work more interesting. Furthermore, the engineer is likely to build toward the need of the customer in every line of code, creating an overall better experience for the end user and a more successful product.
Building done in this way creates a better, more human end result.
A tiny example
While this may work, the question is: who is performing this action? Is this something a user is hitting a button to initiate? In the example above, the user would have no idea what is happening. But with the simple addition of a requestInFlight variable which would change state according the the status of the request, we can show the user that a request is being made.
That tiny example actually happened
At Lyft we built an internal tool to allow our operations team to more efficiently manage driver application documents. The ask was to display the documents and allow our operations and support teams to review them.
But when we looked at who was actually going to be the user of this tool, we learned they could be on any type of internet connection speed, anywhere in the world. In a portion of cases we saw network requests take as long as 7 seconds.
The users with the longer network response time would make many unnecessary clicks across the page which was a waste of time and in some cases made the initial request even slower, filling it with additional requests.
Because we had a better end-to-end picture in mind, we could build for the people actually using the tool and save work down the road needing to add or change features we didn’t know about. Beyond that, there is something inherently gratifying in knowing you did something to make life a little easier for the people who will be using what you made.
This is a very simple example to show that the concept of building for the end user exists in even the most basic project. But, imagine the implications of this concept in building much broader systems, like that for autonomous cars. If we, as engineers, never thought about who would be using these cars, those could be some very unfriendly cars to interact with.
You can do this too!
The most important skill in being able to implement this in your own project is curiosity. Identify stakeholders and work with them to identify the end users. Write down any questions you may have and set up a basic run through of product usage with these end users where they can use an MVP or beta version of what you are making. Be curious. Ask questions to understand using phrases like: “I noticed that…”, “Tell me more about when…”, or “I’m curious, what were you thinking about during…” These types of phrases are open ended and do not blame the end user of misuse. You may get a lot of information from these interactions, work with other members of your team to consolidate what to work on.
This post originally appeared on the Lyft Engineering Blog.