< / >

As a programmer, I have the tendency to break things down from an engineering perspective. It’s a compulsion. Hearing a concept compels me to turn it into a specification in my head.

Specifications can be fundamentally flawed. Theoretical design can be useful, but the sooner you can start building an application the sooner you will find how it actually works in the wild. By creating the specification first, you may find yourself feeling obligated to adjust your frontend to work with the backend you’ve already designed. This is a bad idea. Things never work exactly as you expect. You want to quickly find the errors in your design.

An example from a project of my own: there was an area in our application where the user was creating start-to-finish timed sessions, with timed “breaks” during the session that the users could record. From the eye-in-the-sky perspective, it made sense to store these breaks as a start time and end time.

But by starting with the interface, I realized that entering breaks was a cumbersome process. It caused us to reevaluate it and realize that a simple number of minutes on break during the session was all that was really necessary, not groups of start and stop times. By catching it early on, we avoided the backend work that would have been scrapped in the end.

Interaction with the product is the most important to a user. If you can keep this in mind during your development your product will benefit tremendously from it. The user doesn’t care how your backend is designed, as long as it works for them. Your product should be designed around the frontend. It’s the responsibility of the development team to make sure the backend performs as needed to support the interface.