August 22nd, 2025
My first law of software design is easily the most important lesson I have to offer you in regards to software design. It’s simple enough:
When designing any piece of software, always ask over and over:
What does the user DO?
Answering this question will lead you to a better understanding of the strengths and weaknesses of your design. Among the benefits of applying my first law:
Recognizing the fundamental architecture of your design
Prudent designers create documents that clearly specify the design before beginning to implement it.
Architects use blueprints.
Artists use sketches.
Engineers use mechanical drawings.
Programmers use(d) flowcharts (well, not any more).
Writers use outlines.
Electrical engineers use schematics.
Movie people use storyboards.
So, what do software designers use to organize their thoughts about a design? There have been quite a few schemes cooked up over the years, none of them very useful. For a long time, game designers have used storyboards, but this merely reflected ignorance; nobody had any idea how to schematically define a game, so they simply copied what they use in Hollywood. After all, Hollywood is cool, right? We want to be cool, too, so we’ll do it the same way they do it.
Yep, that was pretty dumb.
The Verb List
Crawford’s First Law of Software Design provides you with a better way to sketch out your design. If you ask “What does the user do?”, the answer, obviously, is a list of the things that they can do. I call this the “verb list” and it is the easiest and best way to figure out exactly what your software will and will not do.
You don’t believe me? OK, here’s a simple challenge to prove my point. I’ll list just a few of the verbs in various pieces of software; you read each short list and figure out what kind of software it belongs to.
Set color
Erase
Use paintbrush
Change font
Insert line break
Set tab
Click on underlined text
Go back
Set bookmark
Turn right
Pick up object
Fire
Reply
Edit text
Delete
Search by title
Play
Skip to next
It’s easy to figure out what these applications do using only three of their verbs. The verbs define the software. So the best way to scope out your software design is to make a list of all the verbs that you want the user to be able to use. For example, when I set out to design Balance of Power, a big hit game of mine in 1985, I started by listing the following verbs available to the player:
Provide military aid to government
Provide military aid to insurgency
Intervene for government
Intervene for insurgency
Provide economic aid
Sign defense treaty
Destabilize government
Apply diplomatic pressure
Each of these eight verbs had five levels of magnitude. It took a lot of work settling on this set of verbs; I considered many variations upon them, as well as a number of others. For each candidate verb, I gave thought to how it would be presented to the player, how its effects would be calculated, and how those effects would be presented to the player. But that constituted most of the design work on the project. From this point, the remainder of the work on the project was just a matter of implementation.