davidbgk
/
larlet-fr-david-cache

title: Your app is not a product
url: https://www.kooslooijesteijn.net/blog/app-website-is-not-product
hash_url: e8ab525499d79428bb5674609dc486dc
archive_date: 2024-04-17
og_image: https://www.kooslooijesteijn.net/_astro/featured-og.BgGmet-N.jpg
description: â¦ and neither is your website.
favicon: https://www.kooslooijesteijn.net/favicon/favicon.svg
language: en_US

<div class="introduction" data-astro-cid-u43ozx4m><p>It’s common to refer to the app or website we’re creating as <em>the product</em>. In digital agencies it can be tempting to have that umbrella term for websites, apps and other computer programs. Especially now UX design is going through an inflationary phase, with the term being abused for over a decade and there are more newcomers to the field than job openings. It’s understandable that some are like, I’m calling myself <em>product designer</em> from now on—people with that role get higher salaries, right?</p></div>
<p>I think it’s wrong to refer to the digital results of our work as ‘products’ though. It’s nothing <em>like</em> real products. For instance, none of the software I’ve been involved in was ever really finished. Not because I didn’t deliver, but because as long as the projects had funding, people were working on redesigns and updates.</p>
<img src="https://www.kooslooijesteijn.net/_astro/factory.DDLi6irg_12k5lP.webp" alt="Simple illustration of a factory with a box-shaped object inside it" loading="lazy" sizes="2em" class="image image--fleuron" data-astro-cid-bj3fsypb decoding="async">
<p>Using the word <em>product</em> for websites and apps can set wrong expectations for clients and business owners. Physical product development needs to be completed before products can be produced and sold, whereas digital services and outlets are regularly developed iteratively, gradually getting better functionality. Until business owners no longer ask what it costs to create a website, their understanding of what a website is and can do is still based on the old notion of buying a physical asset.</p>
<p>Calling software ‘a product’ also contributed to bad parts of programming culture. After all, of people believe code can be ‘shipped’ and the ‘product’ is finished after that. But that leads to engineers shuffling off responsibility and writing code that ‘works on my computer’ and is incomprehensible to future maintainers. I don’t think offending any programmers here, because many I worked with complained about this problem. This attitude of shipping code that only superficially works to pass abstract tests is pervasive though. So pervasive, that despite many countries and the European Union legally requiring accessibility, nearly <a href="https://webaim.org/projects/million/" rel="nofollow noreferrer" target="_blank">all homepages have accessibility errors</a>.</p>
<p>Treating software as a product hasn’t helped the design profession either. Beside industrial designers getting annoyed by UI designers appropriating their job titles, our product-based design processes don’t work well with agile software teams. Methods that require big design up front without considering the value of engineers during that phase are the legacy of physical product development. Designers hanging on to that could be a reason for design struggling to compete with product management and that its influence in organizations <span class="sidenote" data-astro-cid-ic4jgs3n> <input aria-label="Show sidenote" type="checkbox" id="sidenote-1__checkbox" class="sidenote__checkbox" data-astro-cid-ic4jgs3n> <label tabindex="0" aria-describedby="sidenote-1" for="sidenote-1__checkbox" class="sidenote__button sidenote__button--number-1" data-astro-cid-ic4jgs3n> declined </label> <small id="sidenote-1" class="sidenote__content sidenote__content--number-1" data-astro-cid-ic4jgs3n> <span data-astro-cid-ic4jgs3n> <span class="screen-reader-only " data-astro-cid-ic4jgs3n> (sidenote: </span> I hope this is just my subjective experience, but I checked a few companies, just to be sure. Neither Figma, Adobe, Apple nor Spotify have a someone dedicated to design on their boards, while do do have execs for engineering and 'product'. <span class="screen-reader-only " data-astro-cid-ic4jgs3n> )</span> </span> </small> </span>  as a result.</p>
<p>Lastly, treating software like a product is misleading to end users. Nowadays consumers rarely buy a piece of software anymore. If they have the option to pay for a life-long license, it’s often just that: a <em>license</em> to use the software, not the software itself. They can’t sell it to someone else or pass it on to a friend. Even songs and books are ‘sold’ that way: as <a href="https://slate.com/technology/2014/08/digital-assets-and-death-who-owns-music-video-e-books-after-you-die.html" rel="nofollow noreferrer" target="_blank">nontransferable rights</a>. There’s something to say for selling software as a subscription service. Users likely want and expect updates, so that the software works on their new hardware and matches the looks of their updated operating systems. But especially in such a contract, there’s no <em>product</em>; it’s the service of getting regular improvements that customers pay for.</p>
<h2 id="if-product-is-the-wrong-word-then-why-do-we-use-it-so-much">If <em>product</em> is the wrong word, then why do we use it so much?</h2>
<p>From the day I first stepped into the faculty of Industrial Design Engineering of the Delft University of Technology, I loved design. The sheer notion that I could draw something on a piece of paper (I loved that already), turn that into a technical drawing with a computer (imagine using computers! for creative! work!), that people in factories would then make with high tech machines, so people could use the things—so exciting!</p>
<p>A few years later I found it <em>even more</em> exciting that I could skip the part where drawings were taken to factories. Anyone could use the internet to bring digital ideas straight to where ever on earth people would be interested in them. And the methods, skills and mindset I developed by studying design would be <em>so</em> useful to get programmers to work on those ideas with me!</p>
<p>I must be one of millions who went through such a process. Because the internet was so new and growing so fast, barely anyone was trained to create on/with/for it. At the same time, everybody creative and excited enough believed that whatever proficiency they had, was just what was needed to make things online.</p>
<p>As a result, the way I feel about making websites is still influenced by how I learned to think about designing physical products. And that is not unique to industrial design. Graphic design also had, and still has an ultimately linear process. Once the printing press runs, graphic design is finished.</p>
<p>Software development used to be mainly about systems embedded in physical products. Calculators, music players, even computer games were distributed as physical objects. Until phones and other personal computers replaced many of them, most digital electronics had embedded programs that couldn’t be updated. So software developers referring to their ‘product’ were in fact referring to something that existed physically, once it left the factory to be distributed.</p>
<p>Of course, that type of software still exists. But most designers and developers work on websites and mobile apps. Some of them do desktop apps. I don’t have precise numbers, but looking at Stack Overflow and <a href="https://insights.stackoverflow.com/survey" rel="nofollow noreferrer" target="_blank">their surveys</a>, it’s clear that relatively few people work on embedded systems.</p>
<img src="https://www.kooslooijesteijn.net/_astro/factory-with-box.Bsj4uCM9_1MmnpI.webp" alt="Simple illustration of a factory" loading="lazy" sizes="2em" class="image image--fleuron" data-astro-cid-bj3fsypb decoding="async">
<p>Referring to software as a product is an artifact of yesteryears. Almost all software today needs updates. At the very least for security and bug fixes, but also for hardware support and to run well on the systems that they’re created for.</p>
<p>The nice thing about the web is that a <a href="https://web.archive.org/web/19961231235847/http://www.nasa.gov/" rel="nofollow noreferrer" target="_blank">website made in 1996</a> could still work in your freshly updated browser. But it would look old-fashioned, broken even. But for all intents and purposes, the website ceases to exist if the bills aren’t paid for the servers hosting it or the domain name referring to it. Or, in the case of such very old websites, if they don’t have SSL, which make browsers show a big scary dialog that only daring <em>web surfers</em> dare and know how to circumvent. And even if that is taken care of, but the site’s backend software didn’t get updates, we can be pretty certain the original pages will be replaced with SEO spam, links to malware, crypto miners and e-mail spam bots.</p>
<p>With apps it’s not much better. If you’re not updating your app for a while, Apple <a href="https://www.macrumors.com/2022/04/29/apple-outdated-apps-extension/" rel="nofollow noreferrer" target="_blank">will remove it</a> from the App Store. After that, even users who paid for your ‘product’ won’t be able to reinstall it anymore. Not even when restoring a ‘backup’ from iCloud, or when they get a new device. That means that every app maker has to be frank about this: either you commit to working on updates indefinitely, or consider it more like the broadcast of a pilot episode of a series that may or may not be continued.</p>
<p>Committing to long term supports includes overhead like writing release notes, changing app store images and paying the annual Apple Developer Program fee. Made a nice app? Even have many passionate users, but no revenue? Keeping the app alive for 10 more years is going to cost you nearly a <a href="https://developer.apple.com/support/compare-memberships/" rel="nofollow noreferrer" target="_blank">thousand US dollars</a>.</p>
<p>Longevity of apps in the Google Play Store isn’t any better. Just like the Apple App Store’s, its terms are regularly changed. An app that has been through the tedious approval process can be removed after such changes, unless the creators file complaints, provide documentation and change the app’s code or its description.</p>
<p>You could argue these ‘products’ just need ‘maintenance’. But where tangible products may need a drop of lube or a replacement for a worn-out part, software needs to gets different changes each time. Where most cyclists can maintain their own bicycles, software ‘maintenance’ requires the same type of people who created the software. They’re not maintaining it, they’re <em>changing</em> it.</p>
<h2 id="maybe-instead-of-products-we-she-should-speak-of-events">Maybe instead of <em>products</em>, we she should speak of <em>events</em>?</h2>
<p>I don’t think we <em>need</em> new metaphors for the things we do with computers. But I like thinking about creating software as organizing an event. Here are some reasons why I think <em>event</em> is a better metaphor than <em>product</em>:</p>
<ul>
<li>An event can be long and big, like a music festival. It can also be a short presentation. Everybody understands intuitively that differently sized events have different requirements. Whereas with software <em>products</em> today, lots of people tend to believe they need the same planet-encompassing solutions that silicon valley giants have chosen.</li>
<li>Events have an opening date and a closing date. Considering both should lead to a plan for making sure the event is attracting an audience and is safe until it’s closing.</li>
<li>Such a closing date also helps to consider what’s supposed to happen what remains after the event. What happens to the URLs on your site that others linked to? How can app users still access the works they created with your app?</li>
<li>Everybody knows events don’t run on their own. When the organizers and staff leave, things can and will get out of hand. This is why Designer News was and Twitter is made unusable by fascists and spam.</li>
<li>Of course events need to be accessible to wheelchair users and other people with physical and cognitive attributes that are different from the organizer’s. I mean, your users’ need more color contrast in your UIs than your young eyes.</li>
<li>If an event is supposed to happen for longer than an hour or two, you need an efficient, long-term energy supply solution and plans for when and how new visitors arrive and leave, and supplies are delivered. The hosting and updates thing I mentioned earlier.</li>
<li>Technology is required for events to happen, but it’s not the main attraction. Rarely does an event need completely new solutions, so if technicians or designers propose such a thing, one has to verify how the event visitors and organizers would benefit from it.</li>
<li>Events are only successful if enough people come, if these people get along well, and have some diversity as not to bore each other.</li>
</ul>
<h2 id="just-call-it-software">Just call it software!</h2>
<p>I hope you enjoyed considering using <em>event</em> as an alternative for <em>product</em>. Maybe you have an even better metaphor?</p>
<p>I think the simplest, clearest word we can use is <em>software</em>. Even if that word is based on two metaphors (softness and hardware). That doesn’t matter, because software always refers to the programs and files created for computers. And every language is eventually a recursive set of <span class="sidenote" data-astro-cid-ic4jgs3n> <input aria-label="Show sidenote" type="checkbox" id="sidenote-2__checkbox" class="sidenote__checkbox" data-astro-cid-ic4jgs3n> <label tabindex="0" aria-describedby="sidenote-2" for="sidenote-2__checkbox" class="sidenote__button sidenote__button--number-2" data-astro-cid-ic4jgs3n> metaphors and abstractions </label> <small id="sidenote-2" class="sidenote__content sidenote__content--number-2" data-astro-cid-ic4jgs3n> <span data-astro-cid-ic4jgs3n> <span class="screen-reader-only " data-astro-cid-ic4jgs3n> (sidenote: </span> George Lakoff's book <a href="https://www.goodreads.com/book/show/34459.Metaphors_We_Live_By?from_search=true&amp;from_srp=true&amp;qid=zajIIra2ZM&amp;rank=1" rel="nofollow noreferrer" target="_blank">Metaphors We Live By</a> convinced me of that. <span class="screen-reader-only " data-astro-cid-ic4jgs3n> )</span> </span> </small> </span>  based on metaphors.</p>
<img src="https://www.kooslooijesteijn.net/_astro/box.CeljjyXU_1J4WRb.webp" alt="Simple illustration of a box-shaped object" loading="lazy" sizes="2em" class="image image--fleuron" data-astro-cid-bj3fsypb decoding="async">
<p>Of course, sometimes it can be helpful to be <em>more</em> specific. For that we can use the good words we have already, like <em>algorithm</em>, <em>application</em> and <em>website</em>. Not sure I’m on board with terms like <em>library</em>, <em>extension</em> and <em>plugin</em>, but that’s for another time.</p>
<h2 id="now-what">Now what?</h2>
<p>Of course I don’t think this one blog post will change the language that we use to refer to what we create at work. But I hope that it helps refine our thinking about creating software and the processes we use for that.</p>
<p>I want to end with a prediction: future generations of programmers, designers, managers and people in other, new roles in software creation won’t like to use the p-word for what they create. We won’t only have software engineers, but also <span class="sidenote" data-astro-cid-ic4jgs3n> <input aria-label="Show sidenote" type="checkbox" id="sidenote-3__checkbox" class="sidenote__checkbox" data-astro-cid-ic4jgs3n> <label tabindex="0" aria-describedby="sidenote-3" for="sidenote-3__checkbox" class="sidenote__button sidenote__button--number-3" data-astro-cid-ic4jgs3n> software designers </label> <small id="sidenote-3" class="sidenote__content sidenote__content--number-3" data-astro-cid-ic4jgs3n> <span data-astro-cid-ic4jgs3n> <span class="screen-reader-only " data-astro-cid-ic4jgs3n> (sidenote: </span> Obviously, design and product management encompasses much more: user experience, service, business development, customer acquisition—these areas are exactly what most projects need more of. But by referring to all those things as <em>product</em> or <em>UI</em> like we do today, doesn't do them justice either. <span class="screen-reader-only " data-astro-cid-ic4jgs3n> )</span> </span> </small> </span>  and software managers.</p>
<p>True digital natives grow up without the mental bias towards <em>products</em>. When we’re old, remind me to be patient with them kids inventing seemingly arbitrary roles for themselves.</p>