Product design debt versus Technical debt at andrewchen
Статья Andrew Chen проводит параллель между техническим долгом и дизайн-долгом продукта. Инкрементальный подход к разработке — agile, A/B-тестирование, MVP — неизбежно порождает не только технический долг в коде, но и накопление хаотичных элементов в интерфейсе: лишних вкладок, кнопок и ссылок. Классический пример — вкладки Amazon, которые пришлось полностью переработать, а MySpace так и не расплатился со своим дизайн-долгом, что привело к потере трафика. Автор сравнивает загромождённые домашние страницы с визуальным хаосом Лас-Вегаса и объясняет это «трагедией общин»: каждая команда добавляет своё, разрушая общую эстетику. Наиболее уязвимы продукты с множеством функций — соцсети, порталы, игры, ритейл и классифайды. Facebook приводится как положительный пример: компания решилась на глобальный рефакторинг, превратив всё в единую ленту новостей и убрав лишние элементы навигации.
Amazon’s tabs are a classic example of product design debt and the refactoring process to pay it down
Вкладки Amazon — классический пример дизайн-долга продукта и процесса рефакторинга для его погашения
Incrementalism creates Technical Debt, and also Product Design Debt
Most startups these days build products using the various philosophies of agile – both in the formal sense but also the informal sayings of “deploy early and often,” “fail fast,” “ship and iterate,” etc. Coupled with A/B testing, customer development, and thinking through business problems in a scientific, hypothesis-driven way, you end up with a powerful cocktail of techniques to build a modern startup in the most iterative way possible. This kind of incrementalism is mostly great, and people should generally do more of it.
Инкрементализм создаёт технический долг, а также дизайн-долг продукта Большинство стартапов сегодня строят продукты, используя различные философии agile — как в формальном смысле, так и в виде неформальных принципов вроде «выпускай рано и часто», «ошибайся быстро», «выпусти и итерируй» и т. д. В сочетании с A/B-тестированием, customer development и научным, гипотезо-ориентированным подходом к бизнес-задачам вы получаете мощный коктейль методик для построения современного стартапа максимально итеративным способом. Такой инкрементализм по большей части прекрасен, и людям в целом стоит практиковать его больше.
The interesting part is when you get a couple months into your product cycle. You often end up with lots of half-done experiments lying around, an infrastructure that isn’t built to scale, and a mishmash of code that needs to be refactored. Most engineers know that in this kind of a case, the best practice is NOT to rewrite your code, but rather refactor it continually and take down the so-called “Technical debt” so that it’s always under control.
Интересное начинается, когда вы проходите пару месяцев продуктового цикла. Часто вы обнаруживаете кучу незавершённых экспериментов, инфраструктуру, не рассчитанную на масштабирование, и мешанину кода, который нуждается в рефакторинге. Большинство инженеров знают, что в таких случаях лучшая практика — НЕ переписывать код, а постоянно рефакторить его и держать так называемый «технический долг» под контролем.
However, there’s the other side of the coin, which is the product design. After you’ve added a ton of new features and stuck them all on the homepage, you create Product Design debt. The Amazon tabs at the top are a great example of this – you have a design philosophy built around tabs, you scale it as far as you can, and then you have to refactor your design.
Однако есть и обратная сторона медали — дизайн продукта. После того как вы добавили кучу новых фич и разместили их все на главной странице, возникает дизайн-долг продукта. Вкладки Amazon наверху — отличный пример: у вас есть дизайн-философия, построенная вокруг вкладок, вы масштабируете её насколько возможно, а затем вам приходится рефакторить дизайн.
Arguably, MySpace is a company that never paid down their product design debt, and their traffic has been impacted as a result.
Можно утверждать, что MySpace — это компания, которая так и не погасила свой дизайн-долг продукта, и её трафик пострадал в результате.
Anyway, let’s dive into this topic more, starting with technical debt.
В общем, давайте углубимся в эту тему, начав с технического долга.
Technical debt
Most of my readers are probably familiar with the concept of technical debt, but just to re-summarize from this great article on the topic:
Технический долг Большинство моих читателей, вероятно, знакомы с концепцией технического долга, но позвольте кратко пересказать суть из этой отличной статьи на эту тему:
The first kind of technical debt is the kind that is incurred unintentionally. For example, a design approach just turns out to be error-prone or a junior programmer just writes bad code. This technical debt is the non-strategic result of doing a poor job. In some cases, this kind of debt can be incurred unknowingly, for example, your company might acquire a company that has accumulated significant technical debt that you don’t identify until after the acquisition. Sometimes, ironically, this debt can be created when a team stumbles in its efforts to rewrite a debt-laden platform and inadvertently creates more debt. We’ll call this general category of debt Type I.
The second kind of technical debt is the kind that is incurred intentionally. This commonly occurs when an organization makes a conscious decision to optimize for the present rather than for the future. “If we don’t get this release done on time, there won’t be a next release” is a common refrain—and often a compelling one. This leads to decisions like, “We don’t have time to reconcile these two databases, so we’ll write some glue code that keeps them synchronized for now and reconcile them after we ship.” Or “We have some code written by a contractor that doesn’t follow our coding standards; we’ll clean that up later.” Or “We didn’t have time to write all the unit tests for the code we wrote the last 2 months of the project. We’ll right those tests after the release.” (We’ll call this Type II.)
Первый вид технического долга — тот, что возникает непреднамеренно. Например, архитектурный подход оказывается подверженным ошибкам, или начинающий программист просто пишет плохой код. Этот технический долг — нестратегический результат плохой работы. В некоторых случаях такой долг может накапливаться незаметно, например, ваша компания может приобрести другую компанию, которая накопила значительный технический долг, который вы обнаружите лишь после поглощения. Иногда, по иронии судьбы, этот долг может возникать, когда команда спотыкается в попытках переписать платформу, обременённую долгом, и непреднамеренно создаёт ещё больше долга. Назовём эту общую категорию долгом Типа I. Второй вид технического долга — тот, что создаётся намеренно. Обычно это происходит, когда организация сознательно решает оптимизировать настоящее в ущерб будущему. «Если мы не выпустим этот релиз вовремя, следующего релиза не будет» — распространённый рефрен, и зачастую весьма убедительный. Это приводит к решениям вроде: «У нас нет времени объединять эти две базы данных, поэтому напишем промежуточный код для их синхронизации, а объединим после релиза». Или: «У нас есть код от подрядчика, не соответствующий нашим стандартам; приведём его в порядок позже». Или: «Мы не успели написать юнит-тесты для кода за последние 2 месяца проекта. Напишем эти тесты после релиза». (Назовём это Типом II.)
Of course, we are mostly interested in the second type. Eric Ries has a great article advocating for why it’s OK to Embrace Technical Debt. Another great article is from Joel on Software called Duct Tape Programmer. All of these articles are worth reading.
Разумеется, нас больше интересует второй тип. У Eric Ries есть отличная статья о том, почему нормально принять технический долг. Ещё одна прекрасная статья — от Joel on Software под названием Duct Tape Programmer. Все эти статьи стоит прочитать.
I won’t focus too much on the definition since those other posts do such a great job – instead, I think it’s worth talking about why an iterative approach tends to produce technical debt. I don’t think it happens all the time, but there’s always a temptation for it to happen.
Я не буду подробно останавливаться на определении, поскольку другие статьи прекрасно справляются с этим — вместо этого считаю важным поговорить о том, почему итеративный подход склонен порождать технический долг. Это происходит не всегда, но соблазн возникает постоянно.
Ultimately, the problem is that if you are trying to learn something about the business, and your technology is meant just to support that experiment, 99% of the time it’s not worth it to do things the “right way.” The reason is that you don’t know if something is going to work, and as a result, you don’t want to invest in scale or perturbing your entire codebase for something that might be disposable. So instead, you just put a 10% or 25% version of the product out there (now commonly referred to as the Minimum Viable Product) and do as little coding as possible to get there.
В конечном счёте проблема в том, что если вы пытаетесь узнать что-то о бизнесе, а технология лишь поддерживает этот эксперимент, в 99% случаев не стоит делать всё «правильно». Причина в том, что вы не знаете, сработает ли что-то, и поэтому не хотите вкладываться в масштабирование или перетряхивать всю кодовую базу ради чего-то, что может оказаться одноразовым. Поэтому вы просто выкатываете 10%- или 25%-версию продукта (теперь это принято называть Minimum Viable Product) и пишете как можно меньше кода для этого.
The problem is, when the feature is successful, very rarely is a team going to then go back and rewrite it – every experiment creates more questions, and the temptation is to move on to the next question.
Проблема в том, что когда фича оказывается успешной, команда крайне редко возвращается и переписывает её — каждый эксперимент порождает новые вопросы, и соблазн состоит в том, чтобы перейти к следующему вопросу.
Product design debt
A similar problem to this is Product Design debt, which impacts the user experience rather than the underlying technology. The same temptations that lead to technical debt also lead to product design debt, because it’s always harder to do things the “right way” and it’s almost never a rational investment of resources. Show me a site that has great visual appeal, and I’ll guarantee that they don’t A/B test.
Дизайн-долг продукта Схожая проблема — дизайн-долг продукта, который влияет на пользовательский опыт, а не на базовую технологию. Те же соблазны, что ведут к техническому долгу, ведут и к дизайн-долгу продукта, потому что делать всё «правильно» всегда сложнее, и это почти никогда не является рациональным вложением ресурсов. Покажите мне сайт с великолепным визуальным дизайном, и я гарантирую, что они не проводят A/B-тестирование.
Product design debt happens because of scenarios like the following:
Дизайн-долг продукта возникает из-за сценариев вроде следующих:
«Я хочу протестировать эту новую фичу, куда бы её поставить? Может, во вкладки?» «Можно мы закинем этот эксперимент на главную и посмотрим, кликают ли люди?» «Наша навигация уже немного выходит из-под контроля, но если мы её переделаем, большинство разделов сайта потеряют кучу трафика» «Мы только что добавили функцию Списков и хотим её продвинуть — можно просто добавить кнопку рядом с именем каждого пользователя?» «Yahoo только что купил наш стартап, и они собираются разместить нас на своей главной странице!»
(just kidding on the last one)
(последнее — шутка)
The point is, as a product experience grows deeper, at some point the initial design philosophy of just adding more links to a page or more tabs or more buttons just stops scaling. Yet it’s often hard to reorganize the whole site, especially if it means taking a short-term dip on traffic, so the “safe” thing to do becomes to incrementally add things until the user experience is horrible.
Суть в том, что по мере углубления продуктового опыта в какой-то момент изначальная дизайн-философия — просто добавлять больше ссылок на страницу, больше вкладок или больше кнопок — перестаёт масштабироваться. Но реорганизовать весь сайт часто сложно, особенно если это означает краткосрочное падение трафика, поэтому «безопасным» решением становится постепенное добавление элементов, пока пользовательский опыт не становится ужасным.
Kudos to Facebook for looking at their product and deciding that they needed to refactor everything first into a big newsfeed stream of “stuff,” and then all their features into a generic container of apps. They’ve also done a lot to actually remove options from the menu and navigation.
Отдельное уважение Facebook за то, что они посмотрели на свой продукт и решили, что нужно сначала рефакторить всё в единый поток новостей из «всякого», а затем все свои функции — в универсальный контейнер приложений. Они также проделали большую работу по фактическому удалению пунктов из меню и навигации.
Why homepages becomes a Las Vegas visual experience
Incrementally-developed UIs that are never refactored often turn into a Las Vegas visual experience over time. Ya know, something that looks like this:
Почему главные страницы превращаются в визуальный Лас-Вегас Инкрементально разрабатываемые интерфейсы, которые никогда не рефакторятся, со временем часто превращаются в визуальный Лас-Вегас. Ну знаете, что-то похожее на это:
Why does Vegas look this way? I’d speculate that all these buildings are ultimately infringing on the public good of aesthetics, and light pollution becomes a tragedy of the commons. If all of those buildings were to power down, it may be that the relative distribution of business would remain the same, but we’ll never know since that will never happen :-)
Почему Вегас выглядит именно так? Я бы предположил, что все эти здания в конечном счёте посягают на общественное благо эстетики, и световое загрязнение становится трагедией общин. Если бы все эти здания погасили свет, возможно, относительное распределение бизнеса осталось бы прежним, но мы никогда этого не узнаем, потому что этого никогда не произойдёт :-)
Important navigational areas like homepages, inboxes, notifications, etc are all the same way. Each incremental menu item is not a big deal, and provides a lot of value downstream, but a slight incremental cost. But do this enough times, and you’ll start to pollute the overall design aesthetic, which is a public good that all features share.
Важные навигационные зоны — главные страницы, входящие, уведомления и т. д. — устроены точно так же. Каждый дополнительный пункт меню — не такое уж большое дело, он даёт много пользы дальше по воронке, но вносит небольшую инкрементальную стоимость. Но если делать это достаточно часто, вы начнёте загрязнять общую дизайн-эстетику, которая является общественным благом, разделяемым всеми функциями.
For startups, this shouldn’t be a huge problem because you should have a product person who manages the whole experience and can resolve the public good problem. But there’s a danger in bottoms-up startup cultures where anyone can throw up an A/B experiment, which on one hand is great, but on the other hand creates UX pollution. The other class of cultures where this becomes a problem is short-term optimizing cultures, which may have a “feature of the week!” they want to focus on, which they need to exaggerate each feature each week.
Для стартапов это не должно быть большой проблемой, потому что у вас должен быть продуктовый менеджер, который управляет всем опытом и может решить проблему общественного блага. Но есть опасность в культурах стартапов «снизу вверх», где любой может запустить A/B-эксперимент, что, с одной стороны, прекрасно, а с другой — создаёт UX-загрязнение. Другой класс культур, где это становится проблемой, — культуры, оптимизирующие под краткосрочные результаты, где может быть «фича недели!», на которой хотят сфокусироваться и которую нужно преувеличивать каждую неделю.
For established companies with multiple teams competing with each other, this may become a key problem because then it really is a public good within the company.
Для зрелых компаний с несколькими командами, конкурирующими друг с другом, это может стать ключевой проблемой, потому что тогда это действительно превращается в общественное благо внутри компании.
Product types that are most susceptible to design debt
Ultimately, I think product experiences that provide a million little features are the ones that need to watch out the most.
Типы продуктов, наиболее подверженные дизайн-долгу В конечном счёте, я считаю, что продуктовые опыты, предлагающие миллион мелких функций, — именно те, которым стоит быть начеку.
This means:
А именно:
Социальные сети и сообщества, которые хотят объединить чат, форумы, опросы, видео, блоги и т. д. Порталы, которые хотят объединить новости, коммуникации, инструменты и т. д. Игры, которые хотят объединить множество разных миссий, коммуникацию, персонажей, монетизационные активности Ритейл-продукты, которые хотят объединить множество товарных категорий и SKU Сайты объявлений, которые хотят продавать множество различных услуг, товаров, людей и т. д.
All of the above products are hard to design for because they are meant to be open and support lots of diverse activities, but refactoring the UI constantly becomes a strong need as the initial navigation paradigms probably will not scale.
Все перечисленные продукты сложны в дизайне, потому что они по своей природе должны быть открытыми и поддерживать множество разнообразных активностей, но постоянный рефакторинг интерфейса становится настоятельной необходимостью, поскольку начальные навигационные парадигмы, скорее всего, не будут масштабироваться.
I wrote an article a while back specifically on social community sites, called Social Design Explosion.
Некоторое время назад я написал статью конкретно о социальных сообществах под названием Social Design Explosion.
Ideas for when and how to pay down product design debt?
For entrepreneurs out there who are building metrics-driven products but also committed to a great user experience, I would love to hear when and how you pay down the product design debt. Please comment!
Идеи о том, когда и как погашать дизайн-долг продукта? Предпринимателям, которые создают продукты на основе метрик, но при этом привержены отличному пользовательскому опыту, — буду рад услышать, когда и как вы погашаете дизайн-долг продукта. Пишите в комментариях!
Want more?
If you liked this post, please subscribe or follow me on Twitter. You can also find more essays here.
Хотите ещё?Если вам понравился этот пост, подпишитесь или следите за мной в Twitter. Вы также можете найти больше эссе здесь.
I write a high-quality, weekly newsletter covering what's happening in Silicon Valley, focused on startups, marketing, and mobile.
Я выпускаю качественную еженедельную рассылку о том, что происходит в Кремниевой долине, с фокусом на стартапы, маркетинг и мобильные технологии.
Views expressed in “content” (including posts, podcasts, videos) linked on this website or posted in social media and other platforms (collectively, “content distribution outlets”) are my own and are not the views of AH Capital Management, L.L.C. (“a16z”) or its respective affiliates. AH Capital Management is an investment adviser registered with the Securities and Exchange Commission. Registration as an investment adviser does not imply any special skill or training. The posts are not directed to any investors or potential investors, and do not constitute an offer to sell -- or a solicitation of an offer to buy -- any securities, and may not be used or relied upon in evaluating the merits of any investment.
Мнения, выраженные в «контенте» (включая посты, подкасты, видео), размещённом на этом сайте или опубликованном в социальных сетях и на других платформах (совокупно — «каналы распространения контента»), являются моими собственными и не отражают позицию AH Capital Management, L.L.C. («a16z») или её аффилированных лиц. AH Capital Management является инвестиционным консультантом, зарегистрированным в Комиссии по ценным бумагам и биржам. Регистрация в качестве инвестиционного консультанта не подразумевает особых навыков или подготовки. Публикации не адресованы каким-либо инвесторам или потенциальным инвесторам и не являются предложением о продаже или приглашением к покупке каких-либо ценных бумаг и не могут использоваться или служить основой для оценки достоинств какой-либо инвестиции.
The content should not be construed as or relied upon in any manner as investment, legal, tax, or other advice. You should consult your own advisers as to legal, business, tax, and other related matters concerning any investment. Any projections, estimates, forecasts, targets, prospects and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Any charts provided here are for informational purposes only, and should not be relied upon when making any investment decision. Certain information contained in here has been obtained from third-party sources. While taken from sources believed to be reliable, I have not independently verified such information and makes no representations about the enduring accuracy of the information or its appropriateness for a given situation. The content speaks only as of the date indicated.
Содержание не следует рассматривать или использовать в качестве инвестиционных, юридических, налоговых или иных рекомендаций. Вам следует консультироваться с собственными советниками по юридическим, деловым, налоговым и другим вопросам, связанным с любыми инвестициями. Любые прогнозы, оценки, предположения, цели, перспективы и/или мнения, выраженные в этих материалах, могут быть изменены без предварительного уведомления и могут отличаться или противоречить мнениям, выраженным другими лицами. Любые графики, представленные здесь, предназначены исключительно для информационных целей и не должны служить основой для принятия инвестиционных решений. Определённая информация, содержащаяся здесь, получена из сторонних источников. Хотя она взята из источников, считающихся надёжными, я не проводил независимую проверку такой информации и не делаю заявлений относительно её долгосрочной точности или уместности для конкретной ситуации. Содержание актуально только на указанную дату.
Under no circumstances should any posts or other information provided on this website -- or on associated content distribution outlets -- be construed as an offer soliciting the purchase or sale of any security or interest in any pooled investment vehicle sponsored, discussed, or mentioned by a16z personnel. Nor should it be construed as an offer to provide investment advisory services; an offer to invest in an a16z-managed pooled investment vehicle will be made separately and only by means of the confidential offering documents of the specific pooled investment vehicles -- which should be read in their entirety, and only to those who, among other requirements, meet certain qualifications under federal securities laws. Such investors, defined as accredited investors and qualified purchasers, are generally deemed capable of evaluating the merits and risks of prospective investments and financial matters. There can be no assurances that a16z’s investment objectives will be achieved or investment strategies will be successful. Any investment in a vehicle managed by a16z involves a high degree of risk including the risk that the entire amount invested is lost. Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by a16z is available at https://a16z.com/investments/. Excluded from this list are investments for which the issuer has not provided permission for a16z to disclose publicly as well as unannounced investments in publicly traded digital assets. Past results of Andreessen Horowitz’s investments, pooled investment vehicles, or investment strategies are not necessarily indicative of future results. Please see https://a16z.com/disclosures for additional important information.
Ни при каких обстоятельствах публикации или иная информация, представленная на этом сайте — или в связанных каналах распространения контента — не должна рассматриваться как предложение о покупке или продаже какой-либо ценной бумаги или доли в каком-либо объединённом инвестиционном фонде, спонсируемом, обсуждаемом или упоминаемом сотрудниками a16z. Также это не следует рассматривать как предложение о предоставлении услуг инвестиционного консультирования; предложение об инвестировании в управляемый a16z объединённый инвестиционный фонд будет сделано отдельно и только посредством конфиденциальных документов предложения конкретных объединённых инвестиционных фондов — которые следует прочитать полностью и только тем, кто, среди прочих требований, соответствует определённым квалификациям в соответствии с федеральным законодательством о ценных бумагах. Такие инвесторы, определяемые как аккредитованные инвесторы и квалифицированные покупатели, как правило, считаются способными оценить достоинства и риски предполагаемых инвестиций и финансовых вопросов. Не может быть гарантий, что инвестиционные цели a16z будут достигнуты или что инвестиционные стратегии окажутся успешными. Любые инвестиции в фонд, управляемый a16z, сопряжены с высокой степенью риска, включая риск потери всей инвестированной суммы. Любые упомянутые, указанные или описанные инвестиции или портфельные компании не являются репрезентативными для всех инвестиций в фонды, управляемые a16z, и не может быть гарантий, что инвестиции будут прибыльными или что другие инвестиции, сделанные в будущем, будут иметь аналогичные характеристики или результаты. Список инвестиций, сделанных фондами под управлением a16z, доступен по адресу https://a16z.com/investments/. Из этого списка исключены инвестиции, для которых эмитент не предоставил разрешение a16z на публичное раскрытие, а также неанонсированные инвестиции в публично торгуемые цифровые активы. Прошлые результаты инвестиций Andreessen Horowitz, объединённых инвестиционных фондов или инвестиционных стратегий не обязательно свидетельствуют о будущих результатах. Пожалуйста, посетите https://a16z.com/disclosures для получения дополнительной важной информации.
About
Об авторе
Andrew Chen is a partner at Andreessen Horowitz, where he invests in games, AR/VR, metaverse, and consumer tech startups. He is the author of The Cold Start Problem, a book on starting and growing new startups via network effects. He resides in Venice, California (more)
Andrew Chen — партнёр в Andreessen Horowitz, где он инвестирует в игры, AR/VR, метавселенную и потребительские технологические стартапы. Он автор книги The Cold Start Problem о запуске и росте стартапов через сетевые эффекты. Проживает в Венис, Калифорния (подробнее)