By John Maeda6 minute Read

The very nature of business is being transformed by the cloud. In a world where products are no longer finished before they reach users, and incremental improvements are regularly deployed, the relationship with a consumer shifts from buying a product once (owning it) to paying a fee to use it for a set period (renting it). Whereas in the past we might have paid a few thousand dollars for a “finished” piece of software on a CD-ROM, we now pay a few dollars per month for regular access to a cloud-based service.

[Image: Portfolio]

This shift to a recurring revenue model, or subscription business, has many advantages, which include scalability, predictability, and high customer engagement. You’re never making a final sale—and you’re relying instead on regular income through subscription fees. To illustrate this difference, it’s like the distinction between dating and being married: when dating you always want to have your game on, but after getting married you might start taking your mate for granted and get a little lazy. When you’re always “dating” your customer, it’s critical to constantly please them, especially when they’ve come to the end of their subscription period and it’s time to re-up.

The average consumer is now less often the stereotypical nerd of yore, and instead could be someone’s hip over-seventy parent, an iconic reality TV star who’s never used a spreadsheet before, or a teenager who sits at the athletes’ table at lunch instead of the mathletes’ one. A purely functional approach is no longer enough, and instead a richly experiential one has become table stakes because of the relatively new premium standards that have been set by mass market devices and services—think Apple and Instagram.

The minimum viable product (MVP) approach is the minimal or “lean” way to give consumers what they want without it necessarily being a fully realized idea. Given how the cloud works and its unprecedented ability to test incomplete ideas, the MVP approach has become the dominant methodology for pushing ideas out into the world. Although the definition of “viable” is debatable and rightly in the eye of the beholder, because the folks who actually build software systems usually come from an engineering background where “V” will signify being reliable and having as few defects as possible. They want to build a bridge that won’t spontaneously collapse—why bother adorning it with a beautiful floral pattern if it can’t withstand the weight of more than one vehicle?

A techie might be fine with a rough, purely functional experience, since their tolerance for discomfort is already high to begin with. But the general population has grown high expectations for their apps, so it’s become important to redefine “viable” as needing to grant a degree of comfort and a modicum of delight. A professional test pilot in an experimental aircraft doesn’t need a cozy place to sit, whereas a passenger on a commercial jet will expect a pillow and a soda—preferably the whole can. To make this point clearer in an MVP-ridden world of computational products that are missing creature comforts, I like to use the term “MVLP,” where the “L” stands for “lovable.”

Why? Because it’s easy to forget that we’re making viable experiences for more than just technical people who prize reliability and efficiency above all. I like to throw in the “L” to remind ourselves that, whether we think we’re dating or married to the customer, we still need to play a flirtatious game to keep our relationship solid to remain in business with them.

The art and science of design is fundamentally tied to the Japanese philosophy of aichaku (AYE-chaw-kooh), literally “love-fit.” This design word describes that special connection to something in your environment that fits your life so perfectly that you are immediately bonded to it. Being able to frame the construction of lovable, desirable experiences as proximate to the goals of making scalable, robust computational machinery is no longer just a “nice-to-have”—it’s now a “need-to-have.” Brokering this connection between the Temple of Tech and the Temple of Design is something I’ve been doing for most of my lifetime.

A few technology companies have benefited from the practiced vision of people who understand the psyche of software engineers and who have managed to convert that creative energy into experiences that any human being can love without the Temple of Design’s help. So, departing from the usual design success example of Steve Jobs, I like to point to the early work of former Yahoo CEO Marissa Mayer, back when she was VP of search products and user experience at Google. Mayer went in the exact opposite direction from prevailing approaches to visual design on the web by focusing entirely on the time it took for information to get from Google’s cloud onto your machine.

In 2006, Mayer asserted that users “really respond to speed,” pointing out how reducing a Google search from 100 kilobytes down to 70 kilobytes led to a material increase in traffic. Place this in contrast to what was at the time the natural inclination to want to deliver a “designed” experience with many full-screen photographic images and other bells and whistles. I attribute the brilliance of Mayer’s strategy to Google’s newfound position of design excellence, which is rapidly approaching Apple’s, even though most celebratory articles largely misunderstand or omit Mayer’s seminal contributions.

Mayer took something that engineers could understand and measure and then used Google’s in-house expertise to ruthlessly pursue an experience that could be delivered quickly. This is not unlike what the McDonald brothers achieved when they figured out how to deliver a tasty burger at breathtaking speed with their Speedee Service System. They managed to address a fundamental experiential constraint lying at the foundation of well-designed experiences, which I highlighted as the third law in The Laws of Simplicity: Savings in time feel like simplicity.

Google’s ability to deliver experiences with the right choice of engineering perspective strikes me as truly foundational to their product. Although this early approach often became conflated with a minimalist design approach of “less is more,” or with just a nerdly bias, it’s way more than that. It’s the recognition that the “L” in MVLP needs to be taken seriously at the engineering level from the start, because everything depends upon computation. And so Google’s selection of speed as a design attribute stood at the rare intersection of what could be loved by both engineers and nontechies, because when a web page loads quickly, it qualitatively feels divine. And once the technical challenge of achieving speed was mastered by Google, they smartly broadened their “L” approach to include nonengineering attributes such as beautiful, highly compressed imagery such as what is often featured on their home page.

The lovability of an MVP for nontechnical people can only be made possible by bringing businesspeople and designers early into the inception and construction of digital products of any scale. To slap on a business model to a finished computational machine is no longer a winning strategy; by the same token, spraying design all over it after it’s done is a reliable way to lose. An integrated approach is necessary: one that appreciates what developers love to make happen—that is, bridges that don’t fall down—in service of consumers who can pay a fair price for an experience that achieves a satisfying aichaku-style fit.

Excerpted from How to Speak Machine: Computational Thinking for the Rest of Us by John Maeda with permission of Portfolio, an imprint of Penguin Publishing Group, a division of Penguin Random House LLC. Copyright © John Maeda, 2019.


Since when I can remember, there’s always been a lot of discussion about the design process in the design community: Should we do wireframes? Are detailed UI designs a waste of time? Is building a UI kit up front a good idea? Should designers code? After following the discussions for a while and battle-testing it with many different teams and settings I worked with, I can only tell one thing — my process is from now on going to be as little process as possible.

What my usual project is in 2019

In my current setup, my projects are mostly a very broad user experience projects that might also include a bunch of branding or visual identity work. Over the last couple of years my usual client was either a startup or a mid-sized company that is looking to put some structure on their design and product processes until everything gets out of hand. Obviously, the process I use is very malleable and adapted to the needs of the team I work with and it will vary for you as well, this post is just supposed to maybe give you a bunch of ideas for how you can put some structure around your work. I would wholeheartedly recommend not copying what works for me straight up because every person works differently and what works for me might not work for you.

The rough project structure

For the deliverables, assets and so on, I still roughly stick to the setup I outlined back in the 2015. The tools have changed — I rely heavily on Notion and Sync replaced Dropbox these days — but the general structure is the same. I still tend to start new projects with a discovery and research sprint that helps me figure out what is available, what is required and what are the most obvious steps forward.  After the initial sprint I tend to deliver work on a weekly cadence because that way I can schedule things on Sunday evening and have a clear way into the week ahead of me. Things I consider a good baseline for every project are:

  • Basic style guide: I prefer having all the basics in place before designing anything, so the first step when I work is always getting at least base colors, typography choices and basic elements in place. This file is usually a Sketch or Figma library and becomes a base for everything that I do later
  • Versioning: When working in Sketch, I always opt for Abstract. The value it provides in discussion, developer handoff and managing deliverables is simply without compare these days. When I use Figma, I just use Figma to keep everything going.
  • File, Page & Artboard structure: I generally like to keep my pages and artboards well structured. In Sketch I generally do a page-per-functional-section approach, which means if you receive my Sketch file you will most likely see pages like 01 – Login, 02 – Onboarding, 03 – Main UI, 04 – Account settings, and so on. I also usually don’t remove artboards but move them to a separate page in case I want to bring it back from the dead (e.g. ZZ – Rejected). In Figma, I tend to keep Master Components on a separate page as well (e.g. XX – Components).
  • Handoff deliverables: I usually deploy design assets using Figma (or Zeplin/Avocode, I’m not that loyal to my tools) and supplement them with design tokens using tokens encoded with JSON or YAML in a Amazon’s Style Dictionary or Salesforce UX’s Theo format. That way, when working with developers I can refer to things using token names (e.g. card has a border-radius-s border radius and a spacing-m padding) rather than pixels. Documenting your design makes the development handoff way smoother and resulting code way more consistent.
  • Check-ins and 1-on-1s: After every batch of delivered work, I usually prepare a click-through prototype in Figma or Marvel and jump on a call with the team to present and discuss the decisions. These usually happen early in the week since I tend to deliver work in weekly cadence unless something goes very wrong somewhere.
  • Do I need to touch code? This is an important question because while I know how to do things like HTML, Sass or PostCSS pretty well, when it comes to bigger pieces of code (React, Vue, backend stuff) or newer ways of coding up UI, like styled-components or JSS, I am not as fluent in those and that means I will be slower, which I definitely try to flag during the initial meeting. I’m totally okay with learning something new on the job if the clients don’t mind that they might get better quality from someone who specializes in the technology they need.

All four of the things above are usually the first things I try to establish because they mean I can deliver more better work, faster. As you probably noticed, I am pretty much impartial to tools I have to use. Sure, in personal projects I almost exclusively use Figma, Style Dictionary and Vue.js-based coding toolchain, but I don’t mind switching as long as I feel comfortable that I can deliver quality work using the client’s toolkit of choice.

What I generally do

Here are some things that are a good rule of thumb for me in 2019:

  • Hypothesis-driven design: Rather than having user flows coming out of nowhere, I like to work like a scientist: define a hypothesis, design an experiment to test it and take it from there. I have been heavily influenced by the scientific method in my life in general and I love to use it for work.
  • Goals: I am way past the “let’s design Uber for Cats!” phase and I’m very picky about the projects I take on. I generally prefer figuring out a business goal to reach and then figuring out how design can help the client reach that goal. If a client just wants design for the sake of design, we might not be a good fit.
  • Sketches and mockups rather than wireframes: I found wireframes made in something like Balsamiq to be confusing in user testing (having to explain the user what a wireframe is) and I generally find them a waste of time in a world where we have tools like Figma and Sketch. It’s either a paper drawn sketch (which people intuitively understand in user testing) or a full blown, high fidelity prototype.
  • Flow-based deliverables: The minimum deliverable for products for me is usually a Marvel or Figma prototype you can click through.
  • Component libraries and mini design systems: Constraining yourself to reusable components leaves you a lot of wiggle room to stretch your creativity where it matters. At some point, you might be able to get away with sketches on a napkin and short explanation which components those are — exactly what Airbnb is trying to do using AI.
  • Design tokens: Just like with component libraries, it’s just quicker if you define your spacings, paddings and other scales up front and reuse them everywhere. Bonus points when they’re coded up into something like Style Dictionary so developers can easily generate a stylesheet out of them.


Also known as: things I learned the hard way so you don’t have to.

  • Err on the side of overcommunicating, especially when working with remote teams.
  • Document your design: it not only makes everything go way faster, it also makes handoff easier.
  • Know what you’re great at (in my case: 10,000-ft overview down to visual design of the interface elements) and try to outsource everything else (in my case: illustrations and motion design)
  • Learn to fail forward — everything is a lesson, so when you fail, try to deconstruct why something failed and learn from it. You’ll be stronger the next time.
  • Flag things early and be honest — if you don’t feel comfortable doing something, either make sure the clients get that you’re learning as you go (which is perfectly fine in some cases) or that they need to find someone else
  • Don’t worry to push back — this one took me the longest to learn, but you’re supposed to be proud of the work you’ve done, so if you see something in ethics gray zone or straight up bad, make sure you say you’re not okay with it. In the end, your portfolio is a big part of who you attract, so if your portfolio is full of ethically questionable projects, for example, you’ll have a hard time attracting people who care about ethics.

That’s all, folks!

So here you are — this is how my process and learnings look in 2019. If this sounds like something you’d like to try, give it a go and let me know how it went on Twitter. If this sounds like a process of a designer you’d love to work with, don’t hesitate to hit me up as well, maybe we can figure something out.


(photo by Pixabay:

Subscribe to Mariusz Ciesla — Product & Service Designer

Get the latest posts delivered right to your inbox