{"id":25223,"date":"2021-01-19T10:38:58","date_gmt":"2021-01-19T10:38:58","guid":{"rendered":"https:\/\/www.intercom.com\/blog\/?p=25223"},"modified":"2023-12-01T22:26:07","modified_gmt":"2023-12-01T22:26:07","slug":"tackling-complex-design-debt-a-three-step-framework","status":"publish","type":"post","link":"https:\/\/www.intercom.com\/blog\/tackling-complex-design-debt-a-three-step-framework\/","title":{"rendered":"Tackling complex design debt: A three-step framework"},"content":{"rendered":"

Inconsistent product functionality, wildly differing UI components, and conflicting terminology \u2013 the slow creep of design debt can have far-reaching consequences for your business if left unchecked. Here\u2019s a simple framework for managing it.<\/p>\n

A few years ago, we wanted to improve the A\/B testing functionality in some of our targeted messages. It was a trivial feature that we thought would be a cinch to build. But as the self-referential adage of Hofstadter’s Law<\/a> goes, “It always takes longer than you expect, even when you take into account Hofstadter’s Law.”<\/p>\n

So when this five-month-long project reached completion \u2013 at four times the amount of time we had initially estimated \u2013 we were left asking ourselves the question: what went wrong?<\/p>\n

Moving fast makes you slow<\/h2>\n

There is a somewhat legendary startup mantra, initially popularized by Facebook, that says you must \u201cmove fast and break things<\/a>\u201d when trying to scale a product. The thinking behind the saying, which was one of Facebook\u2019s original employee values, is that if you\u2019re not breaking things, you\u2019re not moving fast enough. It\u2019s not a new concept, with IDEO founder David Kelley expressing a similar sentiment in one of his famous tenets of design thinking, \u201cfail faster to succeed sooner<\/a>.\u201d<\/p>\n

In our early days, like many other companies, we prioritized the speed of shipping over maintaining the consistency and interconnectedness of our system. We were a small startup, still trying to figure out what the future held for us, so it seemed reasonable to move fast, regardless of the risk of accruing design debt.<\/p>\n

\n

“Our in-app messages and email messaging enabled companies to reach customers inside the product in real time, so they could deliver the right message, at the right moment”<\/p><\/blockquote>\n<\/blockquote>\n

Initially, our sole focus was developing in-product messaging. Fuelled by our mission of \u201cmaking internet business personal,\u201d we wanted to make it easier for businesses to build personal relationships with their customers at scale. Our in-app messages<\/a> and email messaging<\/a> enabled companies to reach customers inside the product in real time, so they could deliver the right message<\/a>, at the right moment.<\/p>\n

Soon after, we decided to make those available not just for existing customers, but also for potential customers who visited a business\u2019s website and product pages, to help these companies convert visitors to users.<\/p>\n

But since that functionality solved a different problem and we were not clear about how it would evolve, it was viewed as an experiment, and built by a different team as part of a different product offering. This decision spawned many technical and design inconsistencies between similar messaging functionality that was implemented elsewhere in our products.<\/p>\n

\n

“If we had looked a little closer, we would have seen that we were accumulating two distinct types of design debt in our product”<\/p><\/blockquote>\n<\/blockquote>\n

As we were focused on moving fast, it may come as no surprise that this pattern was repeated when we launched our mobile push messages<\/a> and a few years later, when we launched our customizable bots<\/a>. From a distance, these were simply messages that were built in very different ways, for very good reasons. But if we had looked a little closer, we would have seen that we were accumulating two distinct types of design debt in our product: user-experience debt and functional debt. Let\u2019s take a closer look at both of them now.<\/p>\n

1. User experience debt<\/h3>\n

User experience (UX) debt inevitably leads to friction for customers, which leaves you open to having them poached by competitors. It\u2019s the little things that add up over time to really irk a user, and inconsistencies across user interface (UI) components<\/a> \u2013 like buttons, menus, or content \u2013 are all symptomatic of a larger issue at play.<\/p>\n

For us, there were many points of friction in our in-product messaging: from the inconsistent UI experience of building various types of messages, to the conflicting workflows that contained the same steps as another messaging UI, but in a different order.<\/p>\n

For example, when users would segment their audience for in-product messages to existing customers, they would do it through the UI below.<\/p>\n

<\/p>\n

But when they were sending what was essentially the same in-product message to potential customers, the UI would look completely different. So our customers would have to learn the ins and outs of a brand new UI to do the same job \u2013 which unsurprisingly caused a lot of friction for our users.<\/p>\n

<\/strong><\/p>\n

Although differences like these could be considered trivial on their own, together they created a \u201cdeath by a thousand cuts\u201d effect, rendering the product difficult to understand and hard to use.<\/p>\n

2. Functional debt<\/h3>\n

Alongside this issue, we were quietly building another type of debt: functional debt. This stemmed from the fact that different teams had built each of those message types in a unique way, which resulted in some features being deprioritized based on a particular team’s goals and objectives.<\/p>\n

On the surface, there appeared to be illogical inconsistencies across messaging functionality, like scheduling, A\/B testing, or goals. Once again, users were confused, and it didn\u2019t take long for the requests to pile up.<\/p>\n

<\/p>\n

And whenever we built a new feature, we\u2019d literally rebuild it for each implementation so it was available for more than one type of message. This left us at a difficult crossroads: continue to duplicate the work and waste time to satisfy customer needs, or focus on a single message type but create more UX and functional debt.<\/p>\n

The mindset of \u201cmoving fast and breaking things,\u201d despite all of its initial short-term gains, had finally lost its magic, and had made us slow in the long run. We knew we had to change tack and find a way to align teams and functions<\/a> as we scaled.<\/p>\n

A three step framework for tackling the debt<\/h2>\n

Once we knew we had to tackle our debt, we gleaned insights from our previous experiences to produce a three-step framework for reducing it. Here\u2019s how we did it:<\/p>\n

1. Visualizing design debt<\/h3>\n

A part of the problem with solving design debt is the lack of alignment around it. Some people are focused on just their own part of the product, and lack a broader picture. Others have that broader picture, but lack a deep understanding of the details.<\/p>\n

So after we realized the need to change the status quo, our first step was to map out all of the inconsistencies between the different message types. From here, we could create a single unified flow for all messaging.<\/p>\n

<\/p>\n

The initial prototype was rough \u2013 we built it on a hack day. At this point, we prioritized improving the nuts and bolts of the user flow over the aesthetics. But it made the idea tangible and showed that, in theory, everything could be built on top of a single system. This created much-needed alignment on the team, so we could push to get the project added to the roadmap.<\/p>\n

2. The importance of prioritizing and rationalizing designs<\/h3>\n

But as soon as we started talking about prioritizing this work, we met some expected pushback. When weighting a rationalization<\/a> of existing features against building something new that customers are asking for, the former would almost always be deprioritized. A word of advice on this: to make sure you don\u2019t run into a similar wall, it\u2019s important to build a strong customer and business case on why tackling debt is so important. This usually isn\u2019t easy, but it will help you get the result you want.<\/p>\n

Customers are rarely asking you to fix inconsistencies. So instead you should examine indirect indicators: what are your activation rates, or how confusing is your product to people? For example, our product had twice the amount of associated customer conversations tagged with #customer-confusion, compared to any other part of Intercom.<\/p>\n

\n

“We had to spend countless hours reimplementing the same features in a slightly different way, leading to a drastic increase in the time to ship”<\/p><\/blockquote>\n<\/blockquote>\n

You can also explore internal indicators. For example, what are the main things your engineers spend time on? In our case, we had to spend countless hours reimplementing the same features in a slightly different way, leading to a drastic increase in the time to ship.<\/p>\n

Finally, are there any initiatives that might be related to tackling that debt that the company has already committed to? If so, you should try to connect them together.<\/p>\n

Back then, we were developing a new message type, called Product Tours<\/a>, and in order to avoid repeating our mistake of building a completely custom message type in a non-reusable way, we pushed for this rationalization to be done.<\/p>\n

Faced with tangible evidence of this backlog, everyone could see how important it was and knew that it needed to be tackled ASAP.<\/p>\n

3. How to approach design debt<\/h3>\n

If you already have alignment across teams but are unsure of where to start, here are two methods for tackling your design debt:<\/p>\n

1. You can take a bottom-up approach<\/strong>. Let\u2019s say our system consists of these five objects. In the bottom-up approach, you\u2019d first focus on just these two objects, ignoring the rest.<\/p>\n

<\/p>\n

After creating a unified system for them, you\u2019d move on to rationalize it against the next object and so on, eventually arriving at a unified future-proof system. It\u2019s a simple, manageable approach. You solve one problem at a time and for the time being, you ignore the rest. But be warned, such an approach can lead to blindness, as you are only looking at a narrow part of the problem, resulting in the need to re-evaluate previous decisions.<\/p>\n

2. Alternatively, you can take a top-down approach<\/strong>. This involves rationalizing various objects in tandem to create a unified system.<\/p>\n

<\/p>\n

This approach gives you a bird\u2019s-eye view so you can make more future-proof decisions, but it isn\u2019t without its pitfalls. Due to the sheer size of the problem, you may find it\u2019s easy to get lost in the weeds, which can lead to ambiguities and roadblocks.<\/p>\n

Now, as for which approach is better, I think the short answer depends on your product vision.<\/p>\n

Basically, how confident are you in the future evolution of all the things you are rationalizing? Do you know which use cases they would need to support and which capabilities they\u2019d need to have in a year\u2019s time? Do you know if there are any other similar objects being built in the near future?<\/p>\n

<\/p>\n

If all of that is clear, it seems logical to pick a top-down approach, allowing you to rationalize everything in one big swoop. Otherwise, starting bottom-up would make much more sense.<\/p>\n

Yet most projects are more complex than the ones I\u2019ve described above, as the clarity of your product vision may vary widely for each part of your product.<\/p>\n

For example, looking at all the outbound objects in Intercom\u2019s system, we were quite confident about how some of them would overlap with each other and evolve in the future, while for others we were not so sure. To avoid painting ourselves into a corner, we took a holistic look at everything to identify patterns among them.<\/p>\n

<\/p>\n

As we were doing that, we ended up cutting off some of the objects from our rationalization since our vision for them was too fuzzy. Others were fully considered, but were discarded once they reached a point where things started becoming blurry. Finally, we narrowed it down to a list of objects that we ended up rationalizing at a very high level of fidelity.<\/p>\n

<\/p>\n

And this combined approach, of starting top-down and switching to bottom-up, allowed us to have the best of both worlds \u2013 a holistic understanding of how the system should work without getting lost in the complexity of the system.<\/p>\n

Embrace debt<\/h2>\n

Through that process we were able to come up with a unified future-proofed system to support all of our message types. After releasing the changes a few years ago, we saw a 33% decrease in conversations tagged with product confusion, an improved user experience for activation, and a dramatic acceleration in our ability to build new functionality.<\/p>\n

Which brings me back to my initial statement: \u201cMoving fast makes you slow.\u201d<\/p>\n

The truth is, I don\u2019t think it\u2019s actually a problem. Incurring debt is not something to be avoided at all costs. It\u2019s a natural result of operating in a highly ambiguous and fast-paced environment. \u201cMoving fast and breaking things\u201d when your product vision is weak is much better than over-optimizing for a future that may never come.<\/p>\n

But once you\u2019ve strengthened your product vision, it\u2019s time to take a pause, look at everything that you’ve shipped, and create a scalable system to support future growth; one that supports moving fast without the penalties of design debt.<\/p>\n\n","protected":false},"excerpt":{"rendered":"

Inconsistent product functionality, wildly differing UI components, and conflicting terminology \u2013 the slow creep of design debt can have far-reaching consequences for your business if left unchecked. Here\u2019s a simple framework for managing it.<\/p>\n","protected":false},"author":164,"featured_media":25225,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"category":[5],"tags":[24810,12926,153,17828],"coauthors":[429],"class_list":["post-25223","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-product-and-design","tag-design-debt","tag-framework","tag-product-design","tag-product-principles"],"yoast_head":"\nTackling complex design debt: A three-step framework - The Intercom Blog<\/title>\n<meta name=\"description\" content=\"Inconsistent product functionality, wildly differing UI components, and conflicting terminology \u2013 here are three steps to avoid design debt.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.intercom.com\/blog\/tackling-complex-design-debt-a-three-step-framework\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Tackling complex design debt: A three-step framework\" \/>\n<meta property=\"og:description\" content=\"Inconsistent product functionality, wildly differing UI components, and conflicting terminology \u2013 here are three steps to avoid design debt.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.intercom.com\/blog\/tackling-complex-design-debt-a-three-step-framework\/\" \/>\n<meta property=\"og:site_name\" content=\"The Intercom Blog\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/intercominc\" \/>\n<meta property=\"article:published_time\" content=\"2021-01-19T10:38:58+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2023-12-01T22:26:07+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.intercom.com\/blog\/wp-content\/uploads\/2021\/01\/tackling-tech-debt-hero.jpeg\" \/>\n\t<meta property=\"og:image:width\" content=\"1968\" \/>\n\t<meta property=\"og:image:height\" content=\"921\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Alex Potrivaev\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@alexpotrivaev\" \/>\n<meta name=\"twitter:site\" content=\"@intercom\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Alex Potrivaev\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"11 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/tackling-complex-design-debt-a-three-step-framework\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/tackling-complex-design-debt-a-three-step-framework\\\/\"},\"author\":{\"name\":\"Alex Potrivaev\",\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/#\\\/schema\\\/person\\\/1862ac9c0c93c6aadbb4e8755952b3ec\"},\"headline\":\"Tackling complex design debt: A three-step framework\",\"datePublished\":\"2021-01-19T10:38:58+00:00\",\"dateModified\":\"2023-12-01T22:26:07+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/tackling-complex-design-debt-a-three-step-framework\\\/\"},\"wordCount\":2147,\"publisher\":{\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/#organization\"},\"image\":{\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/tackling-complex-design-debt-a-three-step-framework\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/wp-content\\\/uploads\\\/2021\\\/01\\\/tackling-tech-debt-hero.jpeg\",\"keywords\":[\"design debt\",\"framework\",\"product design\",\"product principles\"],\"articleSection\":[\"Product & Design\"],\"inLanguage\":\"en-US\"},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/tackling-complex-design-debt-a-three-step-framework\\\/\",\"url\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/tackling-complex-design-debt-a-three-step-framework\\\/\",\"name\":\"Tackling complex design debt: A three-step framework - The Intercom Blog\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/tackling-complex-design-debt-a-three-step-framework\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/tackling-complex-design-debt-a-three-step-framework\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/wp-content\\\/uploads\\\/2021\\\/01\\\/tackling-tech-debt-hero.jpeg\",\"datePublished\":\"2021-01-19T10:38:58+00:00\",\"dateModified\":\"2023-12-01T22:26:07+00:00\",\"description\":\"Inconsistent product functionality, wildly differing UI components, and conflicting terminology \u2013 here are three steps to avoid design debt.\",\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.intercom.com\\\/blog\\\/tackling-complex-design-debt-a-three-step-framework\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/tackling-complex-design-debt-a-three-step-framework\\\/#primaryimage\",\"url\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/wp-content\\\/uploads\\\/2021\\\/01\\\/tackling-tech-debt-hero.jpeg\",\"contentUrl\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/wp-content\\\/uploads\\\/2021\\\/01\\\/tackling-tech-debt-hero.jpeg\",\"width\":1968,\"height\":921,\"caption\":\"Tackling Tech Debt: A Three Step Framework\"},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/#website\",\"url\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/\",\"name\":\"The Intercom Blog\",\"description\":\"Articles and Podcasts on Customer Service, AI and Automation, Product, and more\",\"publisher\":{\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/#organization\",\"name\":\"The Intercom Blog\",\"url\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/#\\\/schema\\\/logo\\\/image\\\/\",\"url\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/wp-content\\\/uploads\\\/2019\\\/08\\\/Intercom-logo-sq-black-trans.png\",\"contentUrl\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/wp-content\\\/uploads\\\/2019\\\/08\\\/Intercom-logo-sq-black-trans.png\",\"width\":1000,\"height\":1000,\"caption\":\"The Intercom Blog\"},\"image\":{\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/#\\\/schema\\\/logo\\\/image\\\/\"},\"sameAs\":[\"https:\\\/\\\/www.facebook.com\\\/intercominc\",\"https:\\\/\\\/x.com\\\/intercom\",\"https:\\\/\\\/www.instagram.com\\\/intercom\\\/\",\"https:\\\/\\\/www.linkedin.com\\\/company\\\/2491343\",\"https:\\\/\\\/www.pinterest.ie\\\/intercom\\\/\",\"https:\\\/\\\/www.youtube.com\\\/channel\\\/UCJG0MvLP03kyzzAkD-w98aQ\",\"https:\\\/\\\/en.wikipedia.org\\\/wiki\\\/Intercom_(company)\"]},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/#\\\/schema\\\/person\\\/1862ac9c0c93c6aadbb4e8755952b3ec\",\"name\":\"Alex Potrivaev\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/fb86e79198e14b2c6a7480b74f55c50d8b59aaf0484781d6664b82b6f15d3dfe?s=96&d=mm&r=pge5129dd22560bb5c19f784f126d05efc\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/fb86e79198e14b2c6a7480b74f55c50d8b59aaf0484781d6664b82b6f15d3dfe?s=96&d=mm&r=pg\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/fb86e79198e14b2c6a7480b74f55c50d8b59aaf0484781d6664b82b6f15d3dfe?s=96&d=mm&r=pg\",\"caption\":\"Alex Potrivaev\"},\"description\":\"Senior Product Designer at Intercom.\",\"sameAs\":[\"https:\\\/\\\/x.com\\\/alexpotrivaev\"],\"url\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/author\\\/alexpotrivaev\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Tackling complex design debt: A three-step framework - The Intercom Blog","description":"Inconsistent product functionality, wildly differing UI components, and conflicting terminology \u2013 here are three steps to avoid design debt.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.intercom.com\/blog\/tackling-complex-design-debt-a-three-step-framework\/","og_locale":"en_US","og_type":"article","og_title":"Tackling complex design debt: A three-step framework","og_description":"Inconsistent product functionality, wildly differing UI components, and conflicting terminology \u2013 here are three steps to avoid design debt.","og_url":"https:\/\/www.intercom.com\/blog\/tackling-complex-design-debt-a-three-step-framework\/","og_site_name":"The Intercom Blog","article_publisher":"https:\/\/www.facebook.com\/intercominc","article_published_time":"2021-01-19T10:38:58+00:00","article_modified_time":"2023-12-01T22:26:07+00:00","og_image":[{"width":1968,"height":921,"url":"https:\/\/www.intercom.com\/blog\/wp-content\/uploads\/2021\/01\/tackling-tech-debt-hero.jpeg","type":"image\/jpeg"}],"author":"Alex Potrivaev","twitter_card":"summary_large_image","twitter_creator":"@alexpotrivaev","twitter_site":"@intercom","twitter_misc":{"Written by":"Alex Potrivaev","Est. reading time":"11 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.intercom.com\/blog\/tackling-complex-design-debt-a-three-step-framework\/#article","isPartOf":{"@id":"https:\/\/www.intercom.com\/blog\/tackling-complex-design-debt-a-three-step-framework\/"},"author":{"name":"Alex Potrivaev","@id":"https:\/\/www.intercom.com\/blog\/#\/schema\/person\/1862ac9c0c93c6aadbb4e8755952b3ec"},"headline":"Tackling complex design debt: A three-step framework","datePublished":"2021-01-19T10:38:58+00:00","dateModified":"2023-12-01T22:26:07+00:00","mainEntityOfPage":{"@id":"https:\/\/www.intercom.com\/blog\/tackling-complex-design-debt-a-three-step-framework\/"},"wordCount":2147,"publisher":{"@id":"https:\/\/www.intercom.com\/blog\/#organization"},"image":{"@id":"https:\/\/www.intercom.com\/blog\/tackling-complex-design-debt-a-three-step-framework\/#primaryimage"},"thumbnailUrl":"https:\/\/www.intercom.com\/blog\/wp-content\/uploads\/2021\/01\/tackling-tech-debt-hero.jpeg","keywords":["design debt","framework","product design","product principles"],"articleSection":["Product & Design"],"inLanguage":"en-US"},{"@type":"WebPage","@id":"https:\/\/www.intercom.com\/blog\/tackling-complex-design-debt-a-three-step-framework\/","url":"https:\/\/www.intercom.com\/blog\/tackling-complex-design-debt-a-three-step-framework\/","name":"Tackling complex design debt: A three-step framework - The Intercom Blog","isPartOf":{"@id":"https:\/\/www.intercom.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.intercom.com\/blog\/tackling-complex-design-debt-a-three-step-framework\/#primaryimage"},"image":{"@id":"https:\/\/www.intercom.com\/blog\/tackling-complex-design-debt-a-three-step-framework\/#primaryimage"},"thumbnailUrl":"https:\/\/www.intercom.com\/blog\/wp-content\/uploads\/2021\/01\/tackling-tech-debt-hero.jpeg","datePublished":"2021-01-19T10:38:58+00:00","dateModified":"2023-12-01T22:26:07+00:00","description":"Inconsistent product functionality, wildly differing UI components, and conflicting terminology \u2013 here are three steps to avoid design debt.","inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.intercom.com\/blog\/tackling-complex-design-debt-a-three-step-framework\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.intercom.com\/blog\/tackling-complex-design-debt-a-three-step-framework\/#primaryimage","url":"https:\/\/www.intercom.com\/blog\/wp-content\/uploads\/2021\/01\/tackling-tech-debt-hero.jpeg","contentUrl":"https:\/\/www.intercom.com\/blog\/wp-content\/uploads\/2021\/01\/tackling-tech-debt-hero.jpeg","width":1968,"height":921,"caption":"Tackling Tech Debt: A Three Step Framework"},{"@type":"WebSite","@id":"https:\/\/www.intercom.com\/blog\/#website","url":"https:\/\/www.intercom.com\/blog\/","name":"The Intercom Blog","description":"Articles and Podcasts on Customer Service, AI and Automation, Product, and more","publisher":{"@id":"https:\/\/www.intercom.com\/blog\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.intercom.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/www.intercom.com\/blog\/#organization","name":"The Intercom Blog","url":"https:\/\/www.intercom.com\/blog\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.intercom.com\/blog\/#\/schema\/logo\/image\/","url":"https:\/\/www.intercom.com\/blog\/wp-content\/uploads\/2019\/08\/Intercom-logo-sq-black-trans.png","contentUrl":"https:\/\/www.intercom.com\/blog\/wp-content\/uploads\/2019\/08\/Intercom-logo-sq-black-trans.png","width":1000,"height":1000,"caption":"The Intercom Blog"},"image":{"@id":"https:\/\/www.intercom.com\/blog\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.facebook.com\/intercominc","https:\/\/x.com\/intercom","https:\/\/www.instagram.com\/intercom\/","https:\/\/www.linkedin.com\/company\/2491343","https:\/\/www.pinterest.ie\/intercom\/","https:\/\/www.youtube.com\/channel\/UCJG0MvLP03kyzzAkD-w98aQ","https:\/\/en.wikipedia.org\/wiki\/Intercom_(company)"]},{"@type":"Person","@id":"https:\/\/www.intercom.com\/blog\/#\/schema\/person\/1862ac9c0c93c6aadbb4e8755952b3ec","name":"Alex Potrivaev","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/fb86e79198e14b2c6a7480b74f55c50d8b59aaf0484781d6664b82b6f15d3dfe?s=96&d=mm&r=pge5129dd22560bb5c19f784f126d05efc","url":"https:\/\/secure.gravatar.com\/avatar\/fb86e79198e14b2c6a7480b74f55c50d8b59aaf0484781d6664b82b6f15d3dfe?s=96&d=mm&r=pg","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/fb86e79198e14b2c6a7480b74f55c50d8b59aaf0484781d6664b82b6f15d3dfe?s=96&d=mm&r=pg","caption":"Alex Potrivaev"},"description":"Senior Product Designer at Intercom.","sameAs":["https:\/\/x.com\/alexpotrivaev"],"url":"https:\/\/www.intercom.com\/blog\/author\/alexpotrivaev\/"}]}},"jetpack_featured_media_url":"https:\/\/www.intercom.com\/blog\/wp-content\/uploads\/2021\/01\/tackling-tech-debt-hero.jpeg","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.intercom.com\/blog\/wp-json\/wp\/v2\/posts\/25223","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.intercom.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.intercom.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.intercom.com\/blog\/wp-json\/wp\/v2\/users\/164"}],"replies":[{"embeddable":true,"href":"https:\/\/www.intercom.com\/blog\/wp-json\/wp\/v2\/comments?post=25223"}],"version-history":[{"count":0,"href":"https:\/\/www.intercom.com\/blog\/wp-json\/wp\/v2\/posts\/25223\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.intercom.com\/blog\/wp-json\/wp\/v2\/media\/25225"}],"wp:attachment":[{"href":"https:\/\/www.intercom.com\/blog\/wp-json\/wp\/v2\/media?parent=25223"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.intercom.com\/blog\/wp-json\/wp\/v2\/category?post=25223"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.intercom.com\/blog\/wp-json\/wp\/v2\/tags?post=25223"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.intercom.com\/blog\/wp-json\/wp\/v2\/coauthors?post=25223"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}