A Users Hierarchy of Digital Needs

There is some great discussion in the community about the importance of User Experience compared to Developer Experience. Nolan Lawson added a fun analogy to the mix with his piece on composers and audiences, reiterating the fact that users don’t benefit directly from our naval gazing.

Of course, the story isn’t “UX vs. DX!”. It isn’t an outright war between the two, and in fact they can work well together. Unfortunately it is easy to get the balance in the force wrong.

Jake Archibald had another great post on the new streams API for the Web. One of his examples talked about flow control, and how this new capability allows the streams and the platform to work hand in glove:

Imagine we were using streams to download and display a video. If we can download and decode 200 frames of video per second, but only want to display 24 frames a second, we could end up with a huge backlog of decoded frames and run out of memory.

This is where flow control comes in. The stream that’s handling the rendering is pulling frames from the decoder stream 24 times a second. The decoder notices that it’s producing frames faster than they’re being read, and slows down. The network stream notices that it’s fetching data faster than it’s being read by the decoder, and slows the download.

I content that we may have a backlog issue where the communities focus may not be in flow with the platform.

The Hierarchy Of Needs

Back to the diagram above. Here are the pieces of the pyramid and how they fit together in my mind.

Something Worth Doing

First of all, we should be building something that users need or want to do. This doesn’t mean that it has to cure disease, or only be something of social good, it just means that people see a use. Most startups fail because the timing of this use, a lack of marketing it, or the product not being good enough (see below) causes the rest to be moot.

This is the base. Few want to waste time building something that no one cares about. We want to solve problems and should focus here first.

Is Our Platform Capable

I would love to teleport anywhere in the world. Currently we don’t have a platform that supports that however. We next need to map the problems that we see into a solution that can actually work for our users today (ignoring R&D and academia).

We also need to work with our platforms to help prioritize the capabilities of the future. As their consumers, we need to help inform them as they may not be consumers themselves. This is an example of flow control.

• If the platform builds features that aren’t used then there is a bad backlog.
• If the platform doesn’t build features fast enough then we are left to our own devices, which could mean idle hands or leaving the platform.

I believe that one reason that we get a lot of DX tinkering in a community is when the platform isn’t keeping up. There are other reasons for this too however:

• We are in an experimental phase where we have new capabilities that we are pushing and stretching
• Productivity is a bottleneck (see below)

Can Our Users Actually Do It

Now we have the capability for a solution, can we design something that works for real humans. This is where the user experience kicks in to gear. It doesn’t matter if your platform has amazing capabilities if they aren’t wired up in a way that makes them usable.

Can It Perform Well Enough For Them To Keep Doing It

Performance builds from here and has strong ties to the usability and capabilities pieces below. Performance can make or break you. It is often the bottleneck, for example: OCR, VR, speech recognition, AI, etc. We have envisioned how computers could help us in some many places where we have needed R&D across many vectors to make them usable and performant.

Can Developers Fix and Iterate

If we can in theory build a great performing user experience, we then need to make it work in practice. It needs to not take a life time to build features. We need to be able to debug and fix issues in short order. You shouldn’t need to be an enlightened guru to be able to eek out the performance out of the platform, there should be a clear well trodden path.

You can see how all of these fit together and are important. What is the bottleneck for what you are trying to build? It may vary.

We need to work the flywheel across all of these, and when we do so great things happen. Our mobile users have new needs that we need to solve. We need to build offline first experiences that perform well for them and allow them to get their tasks done. We need to have developer ergonomics that allow developers to easily build out these features and keep iterating to solve more problems.

From problems to solution ideas to platform capabilities to user experience to developer experience. We walk up and down the stack all day. One learns from the other. The more we can do to get a reactive well oiled machine, the more we can get done.

This is why I think it isn’t UX vs. DX. This is why I think we need to work together better than ever. Our users are counting on us to do so.