Building for the End-User

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

Take a task of making a very simple request for data via a Javascript promise and logging the response. That would look something like this:

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.

Network latency graph.

What we experienced when developing this tool was a maximum latency of 1 second to make the request.

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.

Unnecessary clicking on long response times.

By implementing the tiny Javascript example above, we were able to show the user what was happening across the network and therefore reduce unnecessary clicks on the page.

Showing the end-user network actions.

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.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s