Comments on: Product design debt versus Technical debt

By: James Shamenski

James Shamenski — Wed, 23 Dec 2009 05:30:05 +0000

Nice Vegas pic from the House of Blues Foundation Room! Certainly doesn't look that lively from my recent visits.

By: PXLated

PXLated — Fri, 11 Dec 2009 04:00:26 +0000

Great article.
Being a designer, I can only speak to the design/ui angle. Have been the design director on some very large well known sites and have faced this a few times with failure and success…
The failure was the original site for a large bank system. All started well but the online VP didn't have the clout to stand up successfully to the VPs with bottom line responsibility. The home page would start out great (usable) but over time every VP would demand that their division also be featured on the home page. Every 6 months or so I'd have to go in and clean house. Organizational structure can affect the design debt. When we redesigned the whole site a couple years later, the new VP of online did have clout and all went well.
On the successful side, I was the design director taking one of the big five retailers online. It was during the dot-com bubble when Amazon was worth more than all the rest of the bookstores combined. There was a lot of pressure from the minions to do many things the way Amazon did. Luckily, I had daily meetings with the pres. and had done a complete analysis of the Amazon site so could clearly explain and demonstrate what worked, what didn't and where they were going to have problems in the future as they expanded. This was during the time illustrated in pic #1. During our dev, Amazon did start expanding and pic #2 was an example of why they were dropping all the tabs and going to #3 and then on to #4. I wanted to run around to all the VPs pressuring for the Amazon way and niener them but didn't Here again, organizational structure affected the outcome.
That big retailer now 8 years later has a tab interface with dropdowns. I've always wanted to go back and find out why.

By: pxlated

pxlated — Fri, 11 Dec 2009 03:40:10 +0000

Sorry onso, the Amazon is not trivial. I think what you're missing is that in the pictorial example the first is the way Amazon started, the second is what would have happened as they expanded – Amazon realized the mess a tab interface creates on scale and skipped to #3. And, Amazon is somewhat a special case as it's been around so long they get by with some things others wouldn't be able to. With their scale, it's hard to totally refractor. eBay and others have tried and failed.

By: onso

onso — Tue, 08 Dec 2009 16:18:52 +0000

the amazon example is trivial. as a amazon user, i didn't even notice all this stuff. amazon connects me to the cheapest prices w/o taxes and shipping charges. I could care less about the rest. this is like saying walmart should optimize the way they lay out their mechandise. Amazon probably has products that can fill 100 walmart megastores. optimizing can be good but it can waste time. and most people who talk about optimizing are just talkers. they don't do anything about it.

By: micahtc

micahtc — Fri, 04 Dec 2009 18:45:08 +0000

There is a bar in the East Village called Burp Castle. It is known as a talking bar. Which means it is an environment set up so you can have normal-volume-level conversations while drinking with friends. In order to avoid the "Tragedy of Commons" – where individuals "talk a little louder to be heard above the noise" repeats until everyone is yelling and no one can hardly communicate – the bar institutes and encourages shushing. Meaning when staff or patrons feel it is getting too loud, they start shushing loudly... until the crowd shushes itself. It works. It's even kind of funny and charming once you're used to it.

My point being, you've effectively articulated a tragedy of commons or institutionalized behavior symptomatic of software-building, user-experience dependent, entrepreneurial organizations. Basically firms that require constant and sustainable innovation as a foundation for business.

As some commenters have pointed out, there are disciplines that can be adopted and made cultural in a software development organization, where reinvention, or refactoring is an institutional norm. The earlier this is engrained in the culture of a growing firm, the more that successfully managing and growing that firm into a sustainable enterprise will consider and depend on thoughtfully balancing the frequency of refactoring with the tolerance of design debt.

Lack of any such process whatsoever results in the classic exposure to competitive disruption as a company's core institutional liability.

Basically, any innovation company has got to consider building in a discipline of shushing in order to keep the conversation alive.

By: manavecplan

manavecplan — Tue, 01 Dec 2009 12:34:21 +0000

Fantastic article Andy…you have no idea of what an eye-opener this is to someone who was considering the design of the website of his startup. I might just touch base with professionals now. Thanx a ton for this…

By: manavecplan

manavecplan — Tue, 01 Dec 2009 12:32:12 +0000

This was probably one of the best articles I've read which would help me in designing the site for my startup. Or outsourcing it entirely. Fantastic…

By: Andrew Chen

Andrew Chen — Tue, 01 Dec 2009 03:43:34 +0000

Great comment, thanks for the thought. Glad to hear that you've figured out a balance.

By: Andrew Chen

Andrew Chen — Tue, 01 Dec 2009 03:42:53 +0000

Amazon has lots of local optimizations that don't make sense from an uber scale My girlfriend actually worked in their UX department and all sorts of stuff drove her mad. But hey, it still works as a business, and Amazon does so many other things right.

I think the core value proposition is so strong that this other stuff doesn't affect it as much.

By: Andrew Chen

Andrew Chen — Tue, 01 Dec 2009 03:41:18 +0000

Yes, it works in the short-term, and that is exactly the danger. The question is, how long does it work before it starts to degrade the experience enough to go the other direction? Leverage is great until you go bankrupt. So there are limits, and it's up to every product designer to figure out what they are.

By: Andrew Chen

Andrew Chen — Tue, 01 Dec 2009 03:39:13 +0000

Thank you sir! I think Mint is an interesting example of this, where the company took a very top-down approach which helps with the overall product consistency, but as you guys have added features you'll need to refactor your design.

By: Andrew Chen

Andrew Chen — Tue, 01 Dec 2009 03:38:19 +0000

I think Steve Blank's advice has a lot of similar with the small-group, qualitative “lead user research” approach of a firm like IDEO. The thing I've struggled with in reading his “4 Steps” book is how to apply it to consumer products and services rather than enterprise. He and I have had some interesting email threads on exactly that issue.

By: Andrew Chen

Andrew Chen — Tue, 01 Dec 2009 03:37:02 +0000

Yes, I think IA and IxD are the toolset needed to address this creeping kind of debt. The question is though, when you're in the middle of a startup going 10,000 feet a second, trying to rapidly iterate and push your product out, what's the right way to build this into your process? Especially when startups are generally started by technically-inclined entrepreneurs that know all the benefits of agile, but all the costs of taking a planning/research-oriented approach?

To me, it starts with the conversation and the business case that this is an important issue to address. IxD and IA are skillsets to address it, but you have to make entrepreneurs CARE about this issue first.

By: yuchiang

yuchiang — Mon, 30 Nov 2009 20:59:12 +0000

Andrew - WGT.com is a metric driven a/b testing culture, but we also have a very strong IA lead and invest a lot in user experience. What we have learned is that you have to be agile and test like crazy but every 3 or so releases we have a product expert review the information architecture and experience to specifically unify, clean-up and refactor the sections that need the most help. We find that you have to book out time and resources on a schedule or else this will never get done. Also we have found that if you target correctly you will see improvements in acquisition numbers and retention, so paying down debt can be ROI positive.

By: Larry McKeogh

Larry McKeogh — Mon, 30 Nov 2009 13:48:11 +0000

Nice way to sum up the pre- and post- product design decisions. I found it very timely since I happen to be wrestling with this type of problem except in a HW application. I think the principles all still apply. The main difference is turn around time and cost.

Fortunately, we have a proven product. So going back to your point "99% of the time it’s not worth it to do things the right way". Now it is a case of refining on that and doing it the right way.

Thanks for the refresher.