Designing products across interfaces
In recent years, we’ve seen more and more products focus on a specific type of audience — developers. These products are designed to cater specifically to the needs of developers and provide them with tools and features that can streamline their workflows. The success of these products lies in their ability to simplify the development process, making it more efficient and productive for developers. Notable examples of this line of products include Vercel, Cloudflare, Stripe, and Auth0, each offering an extremely specialized and unique set of features and functionalities. The rise of developer-focused products is a testament to the growing demand for specialized tools that cater to the unique requirements of developers. These products may address different needs from those of the average user but that doesn’t imply that good user experience isn’t valued.
Designing the user experience for such products, though, may require a little more effort than products with a wider target audience. Designers may require a lot of specialized knowledge and experience with these tools before they contribute to the user experience for these products in a meaningful way. This indirectly implies a longer time to onboard new designers. Additionally, this is not limited to developer-focused products — as software takes over more parts of our day-to-day lives, the same can easily be applied to any product that has a large surface area and may be built to be used by a multitude of audience types.
Bridging the gap
How might we consider bridging the gap between this inherent complexity and the skills designers bring to the table? I’ll try my best to share a few common threads, in hopes they spark some ideas for building better product experiences.
Great, now let’s imagine for a moment that we’re building a comment management system similar to Disqus (which allows you to comment on websites, anonymously or not). I hope most digital designers are familiar with the good ol’ concept of commenting on various forms of media across the web.
What’s the first thing that you want to spend time thinking about — probably some form of visualization of what the thing we want to build is, right? Well, maybe a few of you reading this will point out that isn’t the first thing but to have this guide be a little focused, I’m going to avoid going into all aspects of building a product. Visualization, thus, will likely be the first step to help us understand all the things we may need to build for a successful product — and it’s something everyone can start working from.
Now that we have a visual representation of the product, let’s break it down into what a basic user journey might look like for someone using a third-party application/site/platform that uses this product as its comment management system:
Step 1 — Person X consumes content on the end-user platform.
Step 2 — The comment management system loads existing comments in the background. If no comments exist, it renders an empty state.
Step 3 — Person X writes a comment and hits “Comment”.
Step 4 — The comment management system posts the comment in the background. If the user is logged in, the comment management system posts their username with the comment.
Step 5 — The comment management system renders a loading state and pulls for new comments.
Step 6 — The comment management system renders the new comment in the list.
Great. We’re making progress and hopefully, all of this makes sense so far. Remember the visualization we were started with? That’s only the user interface and since we’re going to be building a comment management system that integrates into different applications or websites, we may want to consider the API (application programming interface: an interface that allows different applications to communicate with each other in a streamlined way) and/or the CLI (command line interface: an interface that only supports text-based commands and runs within a terminal on your operating system) for this particular product. The people that will be integrating this system may be developers and they may want to understand if they can extend the system a little bit. Additionally, we may want to utilize the common practice of dogfooding to help us get feedback as we build the product. We’d probably want to look under the hood of the user journey we’ve been building so far, so let’s take a look at that next.
How to translate from one to the other?
If we were to think about an API for this UI, we’d probably start exactly where our user journey does. A person would navigate to our customer’s application and based on the customer’s implementation of our product within their application, our comment management system would be loaded up in the background. At this point, we probably need our comment management system to request a list of all the comments for a particular page from the customer’s (third-party application) environment or isolated workspace in the comment management product. If we don’t do this — we’d just show an empty block for our product with no actual data…and that’s probably not great.
To represent this, you can follow the visual representation below to see what this interaction would look like behind the scenes. Our comment management system will make a “GET” HTTP request in the background to a specific URL, which will act as a secure middle layer between our product’s user interface and a database where our product’s data is stored.
To learn more about HTTP request methods, you may have a look at the MDN documentation here: https://developer.mozilla.org/docs/Web/HTTP/Methods
The API will make a request in the background to its database to get all the comments available. As these requests are being made, we may want to inform the person viewing the page that we are awaiting data — this is exactly where the ever-welcome loading state interface comes into play, illustrated below.
Once the database is able to successfully return a response, the API can pass the data along to the user interface, which will be able to style and render the data the way we want to visualize it in our product. This final handshake between the database, API and UI is represented below.
Hopefully, we can start to observe some clear patterns in how each interface is communicating with the other and why it’s important for us to define the experience to be able to manage the various intermediate states that may occur in between the interactions. And this is just step 2 of our user journey so far!
If we continue to build out the rest of the user journey, we’ll see that we need to use other request methods for this. This will help us understand the different ways that the user interface, the API and the database are tied closely together.
Let’s start mapping out the rest of the user journey, starting with the person adding a new comment. This will require our comment management system to take the user input in the comment field and pass that information to the API, eventually being added to our database along with the other comments on the article. Our comment management system will now make a “POST” HTTP request in the background to the same URL from the previous request to push the information entered to our API and eventually create a new database entry in the comments table in our database. If everything goes smoothly, we should receive a response from the API saying that an entry for the person’s comment was created in our database. You can refer to the diagram below to visualize this new request and the query to insert the data into our database.
To begin wrapping up our user journey, we’ll need to show the updated list of comments with the person’s newly added comment with a new total. For this, our comment management system will need to refresh the list of comments using the same “GET” HTTP request to get the latest comments from our database. While the system is making this request, we’ll show provide the same feedback to the person that we’re awaiting some data by displaying a loading state in the user interface.
Finally, we should receive a response from our API, we’ll be able to render the received data as seen in the diagram below. And with that we’ve closed out our user journey for listing and adding comments.
Once we begin to look at the different interfaces through the same lens, we see patterns for how to design exactly what a person may need to view, how the system handles this in the background and the different connections you may need to consider. This also brings up a good point around how important it is to consider state when designing an interface, since there is an extremely close relationship between user feedback and responses from any system — this is key to building a great user experience.
Thinking about a different audience
Alright. Now that we got one user journey out of the way, let’s look at another side of our imaginary product — the part that an application builder or developer may need to deal with when they add the comment management system to their application. What are the things they’d need to do to integrate this system with their application? How do they go about this?
The first and most important part that our product would need to provide is an SDK (software development kit) or a CLI (command line interface), which are two different ways that a developer can integrate the comment management system into their application wherever they need it to be plugged in. The SDK is a collection of helpers that can be added into the application directly that allow the developer to easily access methods that the product may offer. For example, the developer may want to have an easy way to render the comment system below an article or they may want to add a custom loading state when the system is awaiting data. The CLI is a way for the developer to have access to the product’s tools via an operating system’s terminal (or command line) — similar to the user interface for a product’s management tool, replacing the UI with text based commands. This can be useful for quickly getting information about how the product is running in the background, for example to get activity logs of the actions being performed in the customer’s environment of our product. These helpers augment how someone can integrate and add the product to their own offering.
Let’s imagine that our customer is building their application and have made the decision to integrate our comment management system into their application. Since we offer a SDK for NodeJS applications (you may learn more about NodeJS here). And hopefully, it is deployed to a cloud-based package management system (meaning you can use it to download packages like our SDK from the internet) like NPM (Node Package Manager). We can assume that a developer may be able to see documentation on our website that points to this SDK, which they can install using NPM right into their application. This step performs a few updates and adds a few files to the local folder for their application:
Once they’ve got the SDK installed, they may want to provide some environment variables to point the SDK to their own environment within our product — this is how an application can potentially authenticate with the product and let it know what to send back (for example — only the customer’s comments and not any customers’ comments). You can see what this looks like below:
The next thing a customer may want to render is the UI for our comment messaging system under each article, they may design their page in whatever language they are building the front-end of their application with. On the skeleton for the article, they can import our SDK and plug it in right below the contents of the article. Additionally, if our SDK offers a nice way to handle data loading, they can add some conditional logic to render a loading UI while the system is awaiting data.
Final Thoughts
Once we begin building interfaces and experiences with their relation to the other services like APIs, SDKs and databases in a system, we can start to map out the different ways people may want to interact with different parts of the product experience. This can help us think about building more consistent patterns across various products, so that users can switch between their contexts and not be lost or confused. Design can, thus, help shape and inform the overall structure and architecture of different interfaces that are crucial for user interaction. Once designers are more aware of the impact of these decisions across the board, it should empower them to create a better overall experience for the products they’re building.
