When you look at most designers’ portfolios, you usually see beautiful, polished work — finished products with plenty of spit and shine.

Those examples are great for showing off your talents and the culmination of your hard work, but the final product is only a small percentage of your total effort. It just represents your last decisions that made the cut.

In reality, most projects are ugly and messy. There are piles of half-baked explorations and heated arguments left behind the scenes. That’s why the shipped version of a design can seem obvious in retrospect — you threw out all the confusing stuff along the way!

Most of this dirty work ends up in the trash or unseen, and that’s too bad. We should all show our dirty work more often, because it’s documentation of the real work. It explains your thought process and gives critical backstory to the final version. (By the way: having that backstory also makes it easier for employers to hire you. Sometimes it’s much more valuable than the end result.)

We’ve been doing this for years in our Design Decisions posts. In that spirit, here’s a bit of our recent Basecamp dirt. This is what it’s really like to make the doughnuts!

Example 1: Should we show a button or not?

Sometimes small things are unexpectedly controversial. When we worked on Archiving Discussions, we had a running debate about whether we should expose the [Archive] button on discussions all the time, or keep it hidden away in a “bulk archiving” mode.

Archiving is an occasional use feature, so we were concerned about making it too prominent. For a while, we even planned to hide the button behind a keyboard shortcut and make it a secret power user thing.

Finally, we all agreed that there was no harm in showing the button. It didn’t get in the way or make the Discussions page noisy — it made it useful.

Example 2: Writing a single link

There wasn’t much design work needed for multiple-file downloads, yet we fiddled with this link text profusely. We even changed it in production after we shipped the feature.

Example 3: Fixing an edge case

Working on a big product like Basecamp means there’s an edge case practically everywhere you look. When we added moving a single to-do, we had to accommodate what happens if there are no destinations to move to. Most people won’t ever encounter this state, but it has to exist for those who do.

Example 4: How should we show attachments?

One of the bigger challenges with attaching files to to-dos was deciding whether we should show each file’s thumbnail next to the to-do itself. To-dos already have a lot of UI chrome, so we wanted to tread lightly. We tried big thumbnails and tiny ones.

After several debates, we decided that big thumbnails were too intrusive, and small ones were too tiny to be useful. So we axed them and opted to show a paperclip icon instead.

Example 5: Basic grammar

There’s often a conflict between proper English and what wording can be programmed to fit a variety of conditions in software. This is why you see computers making silly mistakes like 1 to-dos added successfully. Carefully working around these situations is almost an art in itself. There’s always a push and pull between what you want to say, and what you can reasonably do without excessive conditional code.

During design for making templates from existing projects we included an option to remove to-do assignments in bulk. We had to try several times to find a version that was clear enough and didn’t violate basic English grammar in some way.

So there you have it — those are just a few of our recent examples! What stuff have you made recently that’s itching to see the light of day?