Designing software is complicated. That's why it's best to get your ideas out in the open before getting too far into the project. Outlines are a great way to organize your thoughts and ideas and figuring out where to start. This chapter explains why sometimes you need the grace and power of abstract language, combined with an outline’s orderly structure, to figure out where to go next.

This chapter is from the book

If you want to turn your ideas into software, the first step is to get them out into the open, where you can see them.

It’s easy to think you have a mental grasp of everything you need to do throughout the life of a project. But it’s even easier to overlook something, to fail to account for all the ramifications of a feature, or otherwise to not fully think through the details. That’s fine! Software is complicated. Trying to keep an entire development project in your brain is unrealistic—and unnecessary. Instead, you can craft outlines to get the details written down in a reliable, organized way, freeing your brain to focus on one challenge at a time.

Challenges will come. No matter how thoroughly you think through the project before you get started, you’ll find yourself running into unexpected situations and edge cases. That’s precisely why being prepared is important: first, you need to work out the big-picture stuff and the common cases. Then you’ll have a sensible structure in place to give context to the edge cases and surprises that come along.

Some design challenges are better served by sketching, as you’ll see in Chapter 2. But what about ideas that aren’t concrete enough to draw? Sometimes you need the grace and power of abstract language, combined with an outline’s orderly structure, to figure out where to go next.

The Process: Nonlinear but Orderly

Lots of developers, from hobbyists to seasoned pros, have a habit of following a disorderly (or “organic”) development process. The code itself, and the alpha version of the app, are the design. Features appear when they become the most interesting thing to work on. No documents exist to describe what the app is now or should be in the future.

In that style of development, it’s easy for interface elements to be gradually deposited on the screen like sediment, as new functionality is added. Every time, it seems innocent enough to add just one more little feature, just one more little interface element. Eventually you have an interface design that’s characteristic of “mature” desktop applications that have been accumulating features and user interface (UI) elements for decades. For this reason, “mature” often really means “crufty and cumbersome.”

The more you can define and outline your app up front, the more easily you can avoid this fate. This book presents the practices of turning ideas into software in a particular order:

Outline

Sketch

Wireframe

Mockup

Prototype

But that’s only because they need to be presented in some order; it doesn’t mean you need to follow them in that order. In reality, projects can and do follow a nonlinear and organic process, weaving among those steps via whichever path seems most effective for the design problem at hand—as you can see in Figure 1.1. Even in organizations where the overall software development process is rigid and strict, this sort of frothy, semirandom bouncing around between practices needs to be going on at the lowest levels if you’re going to design anything worthwhile.