Design with the engineering constraints
Thinking like a Developer, Part III
In my previous posts, I talked about how designers can build empathy with developers and apply software methodology to design. Another superpower we can bring into our process is designing with the engineering constraints.
In the world of static mocks and flawless prototypes, software bugs and considerations are invisible. They play hide and seek. If you as the designer don’t find them, your users sure will. When design considers developmental limits, constraints won’t get in the way of design. In contrast, when UX is designed around technical limitations, constraints become your strength.
No matter how good your engineers are, the application you are building will not feel the same between two devices. Internet speed, data usage, and device bandwidth are all technical limitations that result in distinct experiences.
Network speed (3G, LTE etc) across the world and network quality across your living room may vary. In addition, each device will have different bandwidth, which will affect the throughput: Bandwidth refers to the data rate supported by a network connection; the overall capacity. Throughput, is the amount of data that can flow through the connection.
Imagine the network connection as a pipe. Differences in network quality are like occasional leaking. The pipe’s size is bandwidth. Throughput is how much water can run through the pipe. Remember that your application is only one of the sources of water.
You will design realistically, when you bring the imperfect pipe into your process. Try adding loading states to your mocks and stalls in your prototypes. It won’t look pretty! But it will help you understand how your app feels on different people’s hands.
Technical Constraints of Live Video
Personal broadcasting is built upon empathy. People who need a human connection, who want to share a personal story, start live streaming. Their viewers interact with them by asking questions, making comments, and sending hearts — in real time. This way, the viewers become part of the broadcaster’s narrative. So it’s important that the app does not let the broadcaster feel alone.
Live video technology has unique challenges, such as video latency. Latency is the time between an event being captured on the broadcaster side and when the viewer sees it. The network speed as well as the device settings could increase the latency. If the time difference is noticeable, a broadcaster and their viewers cannot be on the same page. Interaction and empathy goes out of the window. To solve this, our engineers introduce an ‘artificial delay’ by tying comments to the video stream. This way thousands of people are able to watch the same comment and video stream at once.
While engineering enables realtime interaction, design builds emotional connection between the broadcaster and her viewers. The concurrent viewer number and hearts they send show the presence of watchers. One benefit of the heart animation is that it builds empathy with a wide array of emotions. The floating hearts blend in with a joyful music broadcast as well as a heart-breaking news story. Also, when the broadcaster’s friends join her stream, their avatars appear at the bottom of the UI. This way your friends avatars make eye contact with you as long as they are watching your stream in real time.
Cost-Effective and Scalable
Engineers refer to some software actions as costly or expensive. These functions require a lot of resources to be used such as the CPU, storage and memory. In order to scale well, we need to implement cost-effective solutions.
Sometimes engineering reduces cost of operation, and design integrates costly operations into a seamless experience.
For example, our engineers reduce the cost of serving broadcasts to thousands of viewers at the same time. Let alone downloading multiple video streams simultaneously, even a single video is not loaded all at once. Instead each stream is divided into chunks. As the viewer keeps watching, more pieces of video are requested from the server. This way, the device’s memory is not overloaded with unnecessary information.
On the visible user interface, design accommodates for the time cost of expensive operations. For example, to make up for the time of loading a broadcast, we display relevant metadata. Similar to the credits at the beginning of a film, we warm up the audience by introducing the broadcaster, their avatar, location and the title.
Video (true) if { Min(cost) && Max(resources) }
Alternatively, engineering and design work hand in hand to minimize cost of operation. For instance, it’s costly to load and display the chats in the stream. So, when a chat room has many participants, we display one chat bubble per second. This doesn’t only minimize the data used to load the chats, but also makes it easier to engage with the messages. Additionally, we prioritize displaying the chats that are relevant to each viewer through personalizing their stream. So for two viewers with different follow graphs, messages will appear differently. This way, your chat room represents your community while we scale the same broadcast to thousands of watchers.
Design Considerations for Engineering Constraints
Network speed & quality is unpredictable.
Test with various connections, in various places. For example, we have a team dedicated to measuring performance in various countries. So we know how our application feels for someone outside of our perfect bubble.
Bandwidth: device capacity is limited.
Do user testing on different devices. Not just Android vs iOS but also different models and different versions.
Throughput: data usage varies and there can be stalls.
Try adding stalls and longer loading states to your prototypes.
Cost-Effective means not relying on memory usage and CPU.
Learn the costly operations on your platform and how they might affect your design process. Also, work with engineers to understand expensive UI/UX decisions. Think twice before you use those in designs and have a good explanation why they are necessary!
I used to believe thinking in code while designing restricts creativity. I wanted my designs to be unprecedented. I knew that conciseness and reusability in programming was important. But I did not see the link between unique designs and the systematic way of code and logic.
I discover that the more I bring my programming knowledge into my design practice, I am able to move faster and iterate more throughout the process. Through the engineer-designer feedback loop, designing for edge cases, and considering the technical constraints, I grow as a designer.
Here is Part I, on how designers can think in code.
Here is Part II, on how to apply software methodology to design.
Follow me on Twitter @asli_kimya, leave a reply, and don’t forget to 👏👏👏 if you read this far! I will share more tips on how to think like a programmer as a designer.
