As SharpestMinds matures as a company, good design is becoming increasingly important. For most of the company’s lifetime, we embraced a design-on-the-fly, just-make-it-work attitude. Without much more than a text or verbal description, we would simultaneously plan, implement, and design new features for our web-app. This approach worked well enough while we iterated towards product/market fit – our early adopters could accept a sub-par user experience because they believed in the mission.

At some point, however, we noticed a shift from market risk (do people want this?) to execution risk (can we deliver a good enough product?). This shift caused us to raise our standards for the minimum in minimum viable product (MVP). New features need to look good, feel good, and map well onto our user’s mental model of the product. This means more effort spent planning and designing.

Shifting to a design-first approach unearthed some of its own difficulties. If the first step in the planning process is a detailed design – fonts, colors and all – it becomes easy to get distracted by minute details instead of taking a step back and thinking deeply about the problem. Planning with design first can also lead to wasted effort. A detailed design can anchor you to a specific implementation and blind you to alternatives. Alternatives that may be much simpler.

Furthermore, when there are a lot of moving pieces, static designs do a poor job at capturing and conveying that complexity. When hidden complexity is discovered while implementing, it can lead to a lot of wasted effort going down rabbit holes or result in band-aid solutions that contribute to technical debt.

The solution is to design and plan at the right level of abstraction. First, take a step back from the design you may have envisioned, even if you feel strongly about it. You need to kill your darlings, as they say. That precious design of yours is blinding you to simpler alternatives. Even better: spend some time trying to understand the problem you’re trying to solve before even considering a solution.

Once you have a solution in mind, you’ll want to answer some fundamental questions before you move on to designing and implementing. What are the major components of the solution? Which parts of the current product will this affect, and how will the pieces interact? To do this, I recommend breadboarding, an incredibly useful concept from Shape Up by Ryan Singer. It’s a word-only method for planning and visualizing the key components of a feature without getting into the specifics of layout or visual design.

Breadboarding with another team member quickly puts you both on the same page. Often, there are a lot of hidden assumptions that each team member will have about how a feature should be implemented. It’s not always obvious what these are until you are forced to sketch out every key piece of the feature and how they are connected.

Breadboarding also lets you visualize the complexity of a feature. A static design can’t show complexity well, but a breadboard full of crisscrossing arrows is a sign that it might be time to simplify. And, because it’s just on paper (or a whiteboard), you can iterate very quickly.

Once you have a breadboard that the team agrees on, come up with some very basic sketches. All the programmer needs to get started is to know what the elements are (inputs, buttons, etc.) , how they interact, and where (roughly) to put them. Any more detail can lead to wasted effort. When I’m building something from a detailed design, I’ll often get side-tracked trying to match the design as well as I can, before I complete a working prototype. Design and styling can take a long time, but it is usually the part of a project that is easiest to compromise on if you’re racing against time.