Today I wanted to write about an approach to getting work done that has worked really well for me. It has come in very handy now that most work is remote-first and asynchronous (thanks COVID).
The gist is essentially, get to a demoable state quick. I think it has significant benefits that go beyond the obvious.
I feel like building a form is a great example that can illustrate the idea. If you are working on building a UI form there’s several pieces to it
- Building the form itself
- Event handlers, Serialization and Submissions
- State management
- Form validation
- Error handling
Looking at it from a lens of demoability - the quickest thing to demo is the UI itself. The rest of it can be layered in after that. So focus on getting the UI first. Once you have that ready, you are in a demoable state.
I use the term demoable loosely. It could mean a screenshot update in a JIRA ticket or a quick slack message to your coworker / boss / anyone that cares about this work. Showing them something to look at takes a lot of the pressure away from the unknown for them and for you. The demo is a good guage of how far out something.
Even if it is a dumb UI with no logic, no event handling or validation, it’s a lot better than “I’m working on it”. I think that’s the point. Instead of verbal updates, showing them specific snapshot of how far you are and also communicating how much work is remaining seems to significantly help in remote work.
Most times people don’t really care about where you are. What they really care about is when you’ll be done. But software estimation is inherently difficult and in following this approach, you take the uncertainty away – to an extent.
Demoing allows you to have conversations like
It looks done but here’s X amount of work that still needs to happen.
Since you layered it after a promising demo, you have a little more leeway to ask for time to do things like refactoring, adding unit tests or performing any other due diligence necessary to ship this feature.
To get to a demoable state soon, the approach is what I normally do for any UI feature. Start with the markup first, then layer on style and then work on functionality.
Of course, there will be iterations and adjustments needed and you will follow the loop over and over but the idea is to work on getting something visual first, then improving it.
I have found instances of this idea in several places. I used to work at an agency and the way we would approach design implementation on mocks was:
- page by page
- top to bottom
- left to right
What this afforded us was the ability to stop at anypoint and jump on a call with the client and show them exactly how far we have come.
Think of it as a progress bar for your work
You can extrapolate this idea to projects in general. Assume you were building an API that needs to be highly available and performant, you start with the most demoable piece of the work first - the API itself. Then you layer on performance improvements and work on it being highly available. You would definitely start with the right tradeoffs for those requirements but you need a working endpoint first before making it performant. You get the idea. This tweet from Addy Osmani in 2013 summarizes this concept well.
First do it, then do it right, then do it better.
Demoing is useful beyond getting people off of your back. That’s a nice benefit but that’s not the only benefit. Having an end product and working your way backwards to fulfill that shifts your perspective. You can quickly interact with what you are building as a user and not the builder. It allows you to be your own PM by automatically prioritizing user-facing issues. You see the product being used rather than just scrambling to get all the pieces to work.
It works especially well for UI work because you have fully functioning prototype that may not be hooked up to a data source or lacking in validation but the feature in its most essential form is great to view and interact with. This is why working on a mockup and iterating there first before writing code is a good idea.
Thinking from a user’s perspective is critical in understanding the feature itself. It unlocks use cases, edge cases that you can’t think when you are looking at it simply to execute the feature itself.
I understand this approach might not always be applicable in all situations. Sometimes what you are working on cannot be piecemeal’d or has several moving parts. But for most use cases, I think this is a hugely beneficial approach to remote work and I can vouch for it personally. It’s great to share progress and updates as well as thinking from a user’s perspective. Also having something to point and talk when you are sharing work updates is a much better approach and usually helps orient everyone to what problems you are running into while working.