Blue Bear has always used some version of the following workflow to develop software features:
- Write User Stories
- Create UI/UX Design
- Define Backend Architecture
- Build It
- Ship It
The core idea is that you should design interfaces and workflows first because it helps you identify what you are actually building, decide if it really solves the problems you want to solve, and clarify any confusion amongst the team.
We’ve recently been working on some projects that have caused us to rethink this workflow a bit.
In one of our projects, one of the primary users is a software developer. Given that, we chose to think of the public API of the code as the user interface.
So far, this isn’t anything unusual. Most people in the industry would nod their heads and say this is what they always do.
While trying to figure out how this fits into our workflow, we decided to write the documentation first. This was our way of creating the UI/UX design before defining the architecture. Essentially, we asked the question, “What code would we love to write if we were the end user?”
This has been amazingly effective at organizing our team communication and collaboration. We each understand the big picture much better than we otherwise would have.
After we came up with this methodology, we discovered that it’s actually already a thing.
One important point to note that Tom Preston-Werner points out in “Readme Driven Development” is that it’s critical to keep things simple. The switch to Agile was a rebellion against Big Up Front Design, and that has led to No Up Front Design in many cases.
We’re not suggesting a reversion to the former, but rather an iterative, design-development workflow where you move forward in the simplest steps possible by writing documentation for what you are about to do first.