Building a software product is hard. While we’ve all heard stories of hero developers cranking out projects in a weekend that go viral, that’s obviously not the norm. For the rest of the world, a smart and diligent approach is needed to build something useful and keep their team (however large or small) on the same page to avoid wasting time.

Over the past 10+ years of building software with teams, I’ve found that the first three steps before building wireframes are essential: (1) list out basic features as you ideate the product, (2) write an overview story of the high-level experience of each type of user, and then (3) build a detailed list of each node (view/page) of the product, writing down from left-to-right and top-to-bottom what should go where (the UI Spec).

The reason why it’s so important to follow these steps closely is to ensure you have very deeply thought about the product and have your team on the same page so there are no surprises later. Ideally the most heated debates should happen at the first stage (informal punch-list of features), and get less heated as you write the overview story and the UI spec.

It’s very common for a startup founder team to not communicate well during this process, where the CEO and CTO — plus anyone else helping them on the product — inevitably have different ideas of what to build. This leads to tons of wasted time as UI elements need to get rebuilt.

Also, at this point, visual designers work best by sketching things out on paper or on a whiteboard. This is fine; people work differently. What’s important is to translate all of this into a written document so the specifications are as clear as possible.

EXAMPLE OF A UI SPEC

While it’s important to get as detailed as possible as you write up the UI spec, keep in mind that you will still be building a flow chart of the user experience and wireframes/mockups where you can make changes as needed before you start writing code.

Thus, the emphasis here after ensuring you are building what you need to test your core value hypothesis, is speed. Write it quickly and get your team on the same page so you can move on to building the flow chart and wireframes.

Using the meetings app I introduced in a previous article, here is an example first draft of a UI spec. Each node has a heading followed by the suggested URL path:

Again, it’s fine to have this in draft form. You won’t have everything figured out in this stage (much will change in your wireframes) but the critical step here is to debate each node with your team to be confident in the direction moving forward.

Functionally, I’ve found that building this in Google Docs and using their inline comment feature is a great (free) way to drill in and debate on specific elements with a team.

Author’s note: this is the 13th post in a series of articles outlining a framework for startup operations that my partners and I at Prota Ventures have developed. We’re also building a SaaS product on top of this framework to help founders spin up new ventures and get connected to co-founders + advisors/investors along the way. Jump into the private beta queue here. Also, feel free to subscribe to my newsletter and I’ll let you know when I get new content up. Thanks!