Paying Off Design Debt
Paying Off Design Debt
Paying Off Design Debt
20 Jun 2005 — 3 Comments
A little over a year ago, we redesigned our stock icon collection website IconBuffet.com. IconBuffet has been running for a few years now, but last spring we launched a couple new collections and the previous design had to go.
Since we had spent quite a bit of time working on the icon collections themselves, we really didn't have a lot of time to spend on site development to market the collections. Consequently, we took on some design debt.
Good Debt, Bad Debt
The term design debt is often used to describe what happens when software developers take shortcuts in order to deliver a product on time. For web designers, this can occur when you opt for inline CSS styles in your HTML document as opposed to externally linked CSS files that only need to be updated once to be reflected in the entire site.Like real-world debt, design debt can come in the form of good debts and bad debts. Some debts, like a low-interest home mortgage where you are able to pay off a reasonable percentage of principal with each payment, are good debts. Others, like high-interest credit cards, are bad debts.
Design is the same way. Sometimes, for the sake of time or other constraints, you are forced to take on a little debt. While it may take you 60 hours to get website design 95 percent valid as XHTML, that last 5 percent may take you another 20 hours. In the grand scheme of things, that's probably not a good use of time. Better to take on the debt (it's okay, your customers won't die), launch the site sooner than later, and then pay off the debt after launch.
For us, getting the IconBuffet website out the door, even if it wasn't ultimately what we wanted was a good debt. It allowed us to begin generating income quickly off of products we had spent a considerable amount of time producing.
We opted for a simple, one-column design, powered with MovableType. It is extremely lo-fidelity. We didn't have the time to invest in developing a customized shopping cart, so we opted to use PayPal instead. In the end, we took on design debt in several places.
However, for the most part, this was good debt. We separated our content from presentation with MovableType; separated presentation from structure with CSS; and used a readily available service in PayPal to process our transactions. We avoided pitfalls by creating modular design elements and images that we could potentially reuse when the time came for a redesign.
And now that time has come... Over the last year, we've added a plethora of new stock icon collections to IconBuffet, and the design is starting to break. The debt we took on a year ago now needs to be paid off.
We probably could have paid it off quite some time ago, but its okay that we didn't. The current site, as it is, has performed very well. It has served its purpose, and allowed us to launch many new collections with relatively low overhead given to site development. The point is that although we took on some design debt, it was a relatively small amount with a low-interest rate. Kinda like getting zero percent for 13 months.
Does this mean you launch shoddy products or websites with half-baked code? That's a quick way to find yourself in design bankruptcy.
Time is money, and in this sense, we believe it's important to be ready to take on small amounts of design debt when necessary. Then, it's equally important to pay those debts off as soon as possible.
What is your experience? Have any debts you're glad you took on? Or, on the other side, do you have any horror stories of bad design debt? I'd love to hear.
Adam Bramwell says
An interesting concept that should allow the obsessive compulsives to make deadlines yet continue to refine in their own time..
Some reasons I can think of off the top of my head for an early launch: linklove and Googlejuice takes time from a SEO perspective; site feedback from a broad user base would be easier to incorporate as the design phase hasn't been completely closed off when released.
We are seeing more and more beta releases these days, with people acknowledging that an imperfect solution implemented now is better than a perfect solution never put in place.
maratz says
You're oh-so right! Been there. However, it sometimes requires defensive approach (i.e. documentation, code commenting, descriptive layers etc.), since after a week or two, it's almost impossible to remember what you meant by doing some temporary fix. And it's almost always after a week or two, cause the minute you launch a web site, another project is already waiting.
Garrett says
Adam - Good call on the betas. The new Ruby on Rails books is taking the same route. They have created a "Beta Book" offering in PDF format that they acknowledge is incomplete, but want to offer as soon as possible for those of us dying to get our hands on that kind of information.
Besides, we're our own toughest critics, and if you think about, the liklihood that others will actually care about the last 5% is slim to none.