During the course of visual research for an internal project, I discovered a simple, illustration-filled book: City: A Story of Roman Planning and Construction, by David Macaulay (1983). Digging into it, I found some surprising parallels between the development of Roman cities and our software development process for how to build an app. I’ve been attempting to come up with meaningful metaphors for software development for a while, so it’s possible I may be reaching, but I think an equally plausible explanation for the similarities herein is that human psychology just hasn’t changed very much in the past 2000 years.
“Because cities were built either where no city previously existed or where a small village stood, the maximum population and size were determined before construction began. The planners then allotted adequate space for houses, shops, squares, and temples. They decided how much water would be needed and the number and size of streets, sidewalks, and sewers.”
“By planning this way they tried to satisfy the needs of every individual— rich and poor alike. The planners agreed that when a city reached its maximum population a new city should be built elsewhere. They recognized the danger of overpopulation. A city forced to grow beyond its walls not only burdened the existing water, sewage, and traffic systems but eventually destroyed the farmland on whose crops the people depended.”
I don’t intend here to fuddle through comparisons of Agile, Lean, Waterfall, and ‘Roman’ processes, but instead to highlight some of the similarities I unexpectedly discovered. Maybe you’ll find something in common with this process as well.
Consider the excerpt above: Whether you are establishing a new market or improving upon and competing with existing mobile apps in the same market, your project scope must be determined before you can begin. You must consult and conduct research, testing your assumptions about who your users will be and what features they will require.
The scope of the app (in this example, a city’s population and purpose) helps determine the features, timeline and resources required for its construction and maintenance. Designers and developers need to remain conscious of the needs and desires of their app’s users.
Pay attention to concerns of accessibility and rely on user research as much as possible; if users don’t like your app, they can and will leave it. Your goal is to keep your citizens satisfied and secure. Still, nothing pleases everyone. Listen to your citizens, but remember that as the principal architects and rulers, your team bears the unique burden of a broader perspective. Scope creep has always threatened the life of projects and something that is difficult to build will also be equally difficult to maintain. Use judgment when evaluating new features to ensure you’ll be able to satisfy your citizens without overburdening your army of engineers.
How to Build an App like Romans Built a City
All quotes and illustrations are from City: A Story of Roman Planning and Construction, by David Macaulay (1983)
I. Identify a Need
The initial concept, the pitch: what problem are we solving, and why?
“In 26 B.C. a disastrous spring flood destroyed the villages along the Po riverbanks as well as an important bridge. When news reached the Emperor Augustus he immediately dispatched to the stricken area forty-five military engineers, including planners, architects, surveyors, and construction specialists. They were to supervise the building of a new bridge and new roads and to lay plans for a new city.”
You’ve identified a problem and you have some early ideas on how it might be solved and how that might benefit your kingdom. In other words, you’ve got a solid elevator pitch and the resources to dedicate to a new project. Now it’s time to back it up with data.
II. Survey the Territory
Discovery — user research studies, competitive analysis, personas and user journey mapping
“First the surveyors selected the place where the city would be built. They chose a flat but sloping site (to ensure good drainage) that was high enough to avoid future floods. A Roman priest examined the livers of a rabbit and a pheasant from the area to find out if it would be a healthy place in which to live. When the animals were found to be without fault and an investigation of the land turned up no stagnant pools, the gods were thanked and the choice of the site was officially confirmed.”
You’ve identified a need and you have some assumptions on how to fulfill it. Now it’s time to test those assumptions. Discover what your citizens need and want. Why would they move to your city if competitive city-states already exist? Are you looking to attract merchants, artists, the political elite? What type of city will appeal to your audience? You could leave those decisions to guesswork and hunches, but if you’re about to dedicate a significant amount of resources to the project, it’s worth the time and money to answer these questions sooner rather than later.
III. Build the Project Infrastructure
Scoping, Project infrastructure, Team-building, Resource allocation, App mapping
“The soldiers and the slaves who traveled with them then set up a military camp called a castrum. First they dug a protective ditch and erected a stockade fence around a rectangular area. Next the two main streets were marked off— one running from north to south, the other from east to west. They crossed at right angles above a long open space called the forum where the soldiers would gather daily to receive their orders. At one end of the forum the commander’s tent was pitched. The tents for soldiers, slaves and supplies filled the remainder of the castrum and were grouped in rows. In the following months all the tents were replaced by more permanent wooden shelters and a temporary bridge was constructed over boats anchored side by side across the river.”
At this point, you know what problem you’re solving and you have a good sense of what you have to build. It’s time to set up the basic infrastructure: security to protect your assets, frameworks to speed up production. Soldiers (developers) and slaves (automated processes) will be the backbone of your construction crew, led by planners and architects. Establish routines for productivity and employee welfare – planning meetings and agreed locations for resources. Your product will start out rough, but will gradually improve piece by piece. Your engineers will be living in this app for some time before ordinary citizens call it home.
Features are shaped by the scope or size of the encampment. An “app map” helps to orient engineers and stakeholders at an early stage, enumerating features and allowing planners to prioritize development.
Designers may recognize the resemblance in their own works.
IV. Draw Up Plans
Wireframing, Flow and User Experience Testing
“The engineers worked throughout the winter measuring, designing, and drawing. By the spring of 25 B.C. (the Roman year 728) the master plan for the City was ready. The center of the castrum became the center of the city. The main street running from north to south was now called the cardo, the one from east to west, the decumanus. Both were widened and lengthened and the rectangular area of the camp was increased to seven hundred and twenty yards long by six hundred and twenty yards wide. This space allowed a maximum population of approximately 50,000. A greater number, the planners believed, would make the city too large and unable to meet the needs of the people.”
You can’t begin building anything without a plan. At this point, we’ve determined a problem, we’ve researched potential solutions, we’ve identified a market for our product. We’ve gotten the funding to begin work in earnest, but before the first brick can be laid we need to figure out where it’s going to go.
With the scope and features outlined in the app map, designers can begin to construct the plans for future development. What features need to live where, how a citizen can get from point A to point B — this is where the User Experience process comes in.
This is an organic process; even though the overall goal remains constant, wireframes and interactive prototypes may suggest better ways of solving certain problems and may result in changes to the original plans.
Architects may build cities, but many different kinds of people also live in them. It is important for designers to regularly test their assumptions by gathering the opinions of future citizens and the opinions of the soldiers building the city. Make sure adequate time is devoted to the process of planning.
Nothing is set in stone with a wireframe; it’s easy to make design changes at this level. Buildings can always be redecorated, renovated or even rebuilt; indeed, this is inevitable and even desirable as your city grows. But when time and money are a concern (and when aren’t they?), it is best to evaluate and test your wireframes as thoroughly as possible to avoid expensive changes later.
“Some of the insulae designated for private ownership were divided up among the soldiers, traders, and farmers. The names of the owners and the sizes of their holdings were inscribed on the plan and sent to the land office in Rome. A copy of the plan was carved on marble and stood in the forum for everyone to see.”
Make sure wireframes are shared with project stakeholders for review and revision, but don’t generate artifacts unless — or until — they’re necessary. Like carvings on marble slabs, documentation is time-consuming to create and adds weight to a project. Flexibility is integral to the process; features are built and improved upon over time, not overnight.
“The master plan allowed much freedom for the residents to determine the appearance and character of the city through the buildings they would construct for themselves. Each insula, left deliberately empty on the plan, would eventually be filled with buildings of all sizes and be crossed by narrow back roads and alleys.”
Wireframes are followed by high fidelity comps as needed. Many screens and components can be reused once designed — a door is just a door, most of the time — so rather than designing hundreds of individual doors, it makes sense to establish a standard and stick to it. Designers that create Pattern Libraries like these get to focus on other features, while engineers only have to build each element once, and users benefit from a more consistent user interface. Everyone wins! Once the wires and high fidelity comps are approved, the building work can be divided between engineers and begun.
Be sure to look out for my second blog in this series: How to Build an App like Romans Built a City: Part II, where I discuss building, testing and improving mobile apps.
