You may have found the Waveguide Next newsletter through the original UX repository at Waveguide.io or simply by discovering it through the Substack network. 

In the last few years, I have moved all my writing to Stone Mind, a Substack publication where design remains at the core of my writing, but where I also explore broader topics and examine the intersection of design with subjects such as philosophy, psychology, and consciousness.

In about a week, I’ll migrate Waveguide Next subscribers and its most valuable posts to Stone Mind.

If you’d rather not be included, feel free to unsubscribe now. If you stay on and receive a newsletter from Stone Mind later but decide it’s not for you, you can always unsubscribe then.

If you’re curious about what’s next, head over to Stone Mind.

Thank you for being a subscriber.

Juan J. Ramirez

But does it really take longer? Nowadays, any good designer with a decent amount of Figma knowledge, a good eye, and good hand dexterity can throw a high-fidelity mockup relatively quickly. I know this is a loaded statement, so let's not focus on the quality of design outputs or actual velocities, but on what designing at that level of fidelity entails.

When I say high-fidelity, I define it as something that has a well-thought composition and layout, uses proper typography and color, and has a decent amount of attention to detail (fair use of effects and strokes treatments). In simpler terms, high-fidelity designs can be a reference for production work.

Of course, designing in high-fidelity will mean different things depending on the product, the company, the process, and the designer. But for the sake of the argument, let's say that high-fidelity designs are mockups that you design with the idea that they will get implemented the way they are. Low-fidelity designs are those that come in the form of wireframes, sketches, or half-baked mockups.

I'm here to argue that those low-fi designs are a significant waste of your time. Early in my career, I discovered that low-fidelity design often resulted in weak design momentum, pointless discussions with stakeholders, and hours wasted trying to reconcile low-fidelity concepts with new high-fidelity designs.

That's the gist of my take. I think wireframes and napkin sketches are fantastic tools for non-designers. I love getting wireframes from engineers and product managers. They are a lens into how they are thinking about a particular feature. I also sketch a lot to ideate, but I never share those. They are often post-it notes that go to the trash-can after they bring clarity to my thought process.

But when I, as a designer, use wireframes as an artifact to push product direction and get momentum, I always get poor results.

Low-fi advocates will argue that low-fidelity designs help stakeholders understand that you're shopping for thoughts on the behavior of the design and not on its form or shape. But why wasting so much time in subtlety when you can literally ask for the type of feedback you want?

Hey, looking for some feedback on this design. Please don't look too much into the aesthetics and focus on the flow and interactions. We can discuss the low level details later when we are aligned on the general behavior. Any thoughts?

It’s as simple as that.

But if you’re still not convinced, let me tell you about testing low-fi designs with users. It won’t work. End users will almost always take designs literally, so they will fixate on the weak (and sometimes confusing) visual constraints of a wireframe. You will be better off by showing them high-fi designs and collecting any potential feedback on how they perceive aesthetics and form.

That's the thing about designing in low-fidelity. It just adds a lot of baggage that will delay your desired outcomes. Designing in high-fidelity puts you closer to your target. It allows you to imagine behaviors and interactions in the environment in which they are supposed to live.

Your designs are also more powerful because you can leverage color, effects, deliberate layouts and information architectures to build the product narrative that you intend to develop.

You also can design one high-fidelity set and iterate from it until you reach your desired outcome. People understand your vision because your design is a full expression of it, not a poor proxy.

When designing from low-fi, you have to repeat and rebuild so many things. You have to re-evaluate so many decisions, and you will almost always make costly mistakes and introduce an unbearable amount of latency to your process.

This graph explains the issue a little bit more eloquently:

When you design in high-fidelity you're always working on the same ground and using the same rails to your destination. It simplifies the design process by several orders of magnitude.

I know that low-fi design looks on paper like the right way to iterate and build a product. In fact I was taught over and over that designing in low-fi was a more efficient way to build product. Even design managers will suggest it from time to time but mostly because they were concerned about my bandwidth, not because they felt that was the right way to design a product.

Believe me, once I learned how to produce high-fidelity designs faster, I realized how useless it was to design at lesser fidelities.

I like to think of a chef that wants to experiment with a new exotic seasoning and starts testing it on microwave food. That's how low-fi designs feel to me.

You should be testing your exotic seasonings in equally high-quality base ingredients. Anything else puts you further away from your desired flavor.

Quick disclaimers:

• No, I’m not saying you should stop wireframing or sketching. I still do that. I’m arguing that you should stop using those in your visible process.

• High-fidelity is a wide spectrum. If you’re designing a very intricate consumer experience you probably want to design at a mid-fidelity and bridge the gap at the end. The idea here is still the same, though. Design as close to the production fidelity as you can get, without sacrificing speed.

• This is an opinion. Thousands and thousands of succesful designers use low-fidelity in their process and they have successful careers. As I grew in my own design career I stopped seeing the merits of low-fi design but I’m not invalidating its value in a general context. I just think there are smarter ways to work. Would love to hear different opinions.

As awalys, eager to learn your perspectives and own takes. You can reach out and let me know what you think on Twitter @whoisjuan.

Now that we are past the clickbait, yes, you're an idiot for not designing with screenshots.

But before I say why first let me explain two things. One, what's "designing with screenshots," and two, why should you be listening to me.

So first, designing with screenshots is this idea that when designing software, you can screenshot existing areas of the application and use them in your designs to create the final composition of a mockup—this instead of drawing every UI element from scratch.

And before you say, "what about designing an app UI from scratch?"...Well, sure, but let me give everyone a reality check here and say that that is almost always not the case. Also, if that’s your case, you’re a martyr because that’s a brutal daily job.

Now, who am I? I'm just a designer trying to have fun working in tech. That has taken me through many companies directly and indirectly. Some of those companies are Facebook, Amazon, Gitlab, Procore, and a handful of startups and mid-sized tech companies.

So all this to say, I've been around trying to grow my tech career. And for better or for worse, I think that I have developed a good sense of what works and what doesn't. Or, in other words, I'm showing you my credentials, so you don't think I'm another idiot.

Ok, now that that's out of the way, let's return to what I wanted to share today, which is that you're an idiot for drawing all those shapes or using your company's broken component system in Figma.

So in classic BuzzFeed fashion, here are five reasons why you're an idiot for not designing with screenshots:

1) Because it makes you faster

Ok, so this one is obvious, but I don't think people understand how much faster you can be if you design with screenshots. Let's assume that you are designing a web app, and you need to create a view with a sidebar. Your component library has it, but you need to customize a bunch of shit to make it look the way you need it to look.

But there's also an implemented sidebar in the actual browser app that looks the exact way, and it's in the same state you need it.

So what do you do? You drop the component, detach it and change all the stuff you need to change? Or you screenshot the real one and drop it on your frame?

If you're doing the first one, then you're clearly an idiot. Both mechanisms will give you the exact visual representation of what you need. Only that one is way faster than the other one.

2) Because nobody cares about images in your designs

Ok. So you're a design purist, and you want to satiate your OCD tendencies with perfect designs drawn 100% from shapes. Well, you're an idiot. You're just working harder, not smarter.

The reality is that nobody cares about images in designs because nobody cares about hand-off practices—only designers and developers working on design systems, working on refining already high-caliber consumer experiences, or companies with outsourced teams. The rest of us are just trying to ship some shit.

Also, if you know what you're doing, your designs will be as pixel-perfect, if not more, than your hand-drawn and dragged designs.

I must confess that I used to worry about how it will reflect on my work if someone decided to inspect all my mocks and found many stitched images and shitty mockup makeup. But I grew on my career and found out that people were not even remotely concerned about this. It's far more critical to have the ability to create visions and set strategic directions through your designs than it is to have tidy Figma files.

3) Because it helps you understand and keep design precedent in your designs.

Your app is not perfect. Just admit it. There's more tiny nuance in the products we help design than we like to admit. This impacts the way you design any app, from growing particular areas of the UI to adding new features in existing views.

Designing from screenshots allows you to understand UI nuances that are only clear when working with a screenshot as a starter. It enables you to make design decisions that are based on the existing implementation.

But more importantly, it helps you focus on precisely the areas of the UI you're trying to change—no need to redesign what's already implemented when you have no plans to touch it at all. If you're doing that, you don't value your time.

4) Because it's another tool under your belt

Look, before I give the wrong impression and make you think I'm just a guy screenshotting UIs and cropping screenshots all day, let me say that I spend a lot of time designing UIs with actual library components and shapes.

Sometimes I do have existing designs using components that are better starters than a screenshot.

Other times I need to design a completely new view, or sometimes there are no decent design precedents to use as a starter.

There are also rare occasions where I need to design something that requires a formal design hand-off with specs and a pixel-perfect design.

What I'm trying to say is that just because you're good at composing new UIs from screenshots doesn't mean that you're not good at designing from scratch. It's just intelligent to use each tool for different needs.

5) Because being a great designer has nothing to do with being great at drawing shapes

Many junior designers and industry newcomers fail to understand that creating UI mockups and UX narratives is just a tool of the job. Not the job. Your job is to collaborate with cross-functional partners to develop a product that fulfills your customers' needs. Your job is to set a strategic direction of what should matter for your product's user experience to be successful. Your job is to enable alignment and discussion by creating artifacts that allow people to imagine a future.

Of course, you need to be a great hands-on designer to be successful at your job. Just because you can produce a design artifact faster using screenshots doesn't mean that you can't let go of your intentionality and design excellence. The idea is that you can achieve those things with fewer steps and less effort.

Designing from a screenshot can sometimes help you deliver more value at a faster rate. High output designers are very valuable, and it's surprisingly easy to become one if you work intelligently.

There you have it. Now you can tell me why I am wrong.

But jokes aside, please let me know what you think on Twitter @whoisjuan.

I have had the opportunity to build a career by integrating this tool into my repertoire of design tools. My sincere take is that many people should consider it if they work in highly iterative, fast-paced, and collaborative environments. Of course, there are situations in which this tool is not a good approach, but part of being good at designing with screenshots is to identify when it is a good idea and when it is not.

Imagine you're a small but innovative burger joint. You have an excellent burger and fries combo, and people rave about it. Your burger joint is a to-go place, so as part of their burger and fries purchase, you give your customers some traditional ketchup packets (those with barely any ketchup in them and that are hard to open and use).

I'm not too fond of that type of ketchup packaging. You could even say I hate it, but I still will use it and won't overthink it. It's not something that is going to stop me from going to your burger joint.

Most people fall into a similar spectrum. They don't care about it, or if they do, it's not something that they will use to object to the quality of your burger and fries combo.

Now, the problem is that you're not trying to build a humble burger joint. You want a chain. You want to scale and have a memorable brand. So you want to be meticulous about things other people are not meticulous about. That's your competitive advantage.

So you decide to make a difference there and in many other areas. You have several options. One is to be generous with the number of packets you give your customers. Instead of 3, you could give them 5. But that's not going to solve the frustrating nature of the package.

Or you could buy ketchup that comes in a bigger and more user-friendly package. However, that type of packaging is more expensive. In terms of packaging, two “dip and squeeze” packages are twice as expensive as five traditional ketchup packets.

You see, UX is a little bit like that ketchup problem. Hiring a UX Designer is a significant investment. And it needs to be significant because there's no worse first UX investment for a startup than hiring an inexperienced UXer.

The problem is that most startups have limited resources. When adding your first UX headcount, you're taking one away from engineering or sales. So it's tempting to delegate this work to contractors or, what's it's worse, to get in charge of the UX yourself.

Now, I have been incredibly unfair with this analogy because UX Designers have more impact on your business than a mundane ketchup package. UX Designers can bring a new level of clarity and correctness to your product that you won't get from your PM, your engineers, yourself (if you're not a designer), or that folk in marketing who knows how to create pretty marketing materials.

But what's helpful about this analogy is that it explains clearly why most people dismiss their needs for a design contributor at their organizations. Like in that ketchup analogy, sometimes it's just easier and cheaper to give more of those traditional packets than to invest in this abstract new thing. And that's the problem with the idea of investing in design at your organization. Sometimes design is so abstract that it feels unnecessary or financially antagonizing.

The reality is that most startups need UX design way earlier than they realize. We live in a world of commoditized user experience. Most popular internet services, apps, and professional software are highly optimized user experiences designed by comprehensive UX teams. They are all not perfect, but many of these organizations are seeking perfection.

If you're developing consumer software, that's your bar. If you're developing business software and want to win for real, that's also your bar. 

Offering software riddled with inconsistent patterns and confusing user flows actively hurts your chances of winning the trust and loyalty of your customers.

Most founders I have talked to know this, so their question is never if but when. The question is relatively easy to answer.

Make your first design hire (assuming you have the headcount) when one or more of the following situations apply to your current state of affairs:

• If you have used your software in the last two months and found something you personally perceived as confusing.

• If you have been hiring UX contractors and at a certain point you felt that process could be faster or better or that it would be easier if that person were more involved and embedded into the team.

• If you have a non-designer role like a PM or a Marketing Contributor, designing user interfaces.

• If other cross-functional contributors have started asking for more design support than the one that they currently have (e.g: contractors)

Of course, not all situations are the same, and there could be scenarios where other hires are more critical to ensure the short-term success of your business. 

If that's your case, don't sweat it. Prioritize your essential hires, but document cross-functional needs and potential responsibilities for a UX hire. Once you have the liquidity to make a UX Hire, you will be glad that you have a clear idea of who you want and the impact you want them to make at your company. This scenario is especially true for VC-backed companies that are likely to face this urgency to fill voids once they raise new capital.

In any case, the message that I have for Founders is clear. UX Design is an important area of your product development model. Developing too much product without a UX professional will almost certainly lead to unusable software. The earlier you can embed this role into your working model, the faster you will gain the product quality you're seeking.

Hi Dear Friends,

If you’re reading this is because, at a certain moment in the last 3 years, you signed up for Waveguide. If you didn’t sign-up recently, it’s possible you don’t remember what Waveguide is.

Waveguide is a design hub that documents and organizes examples of UX, UI, and Brand Identity and augments it with data like color, reading insights, and categorization.

I created Waveguide because I wanted to solve a problem I had in my profession. As part of my job as a User Experience Designer, I would often reference existing products or designs to find inspiration or ideas. This is an activity that nurtures my creative process and my ability to ideate newer innovative designs.

At the core of this idea, there was also a desire to show people how I perceive the world when designing. I have always felt that great designers can see a great design in small details and isolate it from the noise of a chaotic world.

Waveguide grew up to be a product that showed multiple design examples across different verticals and platforms. I know that Waveguide has helped many people find inspiration and learn about UX Design. In the past 3 years, Waveguide has been frequently visited by more than 100K unique visitors from all over the world.

Life is about cycles and today is the time to end one and start a new one. Although I love everything I created and learned with Waveguide, I never really felt like I was on a meaningful trajectory with it. My dream for Waveguide was to create an authoritative repository of design examples, and that turned out to be harder than I expected.

So today, I’m letting you know that I’m shutting down the original Waveguide and will seek and pursue new ideas. However, I have some good news in this regard…

What’s Next?

My original dream with Waveguide was to share with the world how I perceive design when applied to real problems. I still want to do that (more than ever), so I created this Blog / Newsletter to fulfill my desire of teaching the world about design. I called it Waveguide Next because this is what’s next, and I still like the brand. 😆

I hope you consider staying subscribed to the newsletter. I have also decided to keep a static version of my favorite Waveguide content (the UX examples) under the original domain name and keep adding new examples. I will update you about new examples through the newsletter.

I’m deeply grateful for your support and for being part of this journey! I have many ideas, lessons, and thoughts to write about, and I’m very excited to share those with you in the upcoming months.

Sincerely,
Juan (JJ)

Quick Recap / TL;DR

Here is a quick recap of what’s changing:

1) Waveguide, as you know it, will go away effective immediately.

2) A static version of Waveguide’s UX Examples will still be live at https://waveguide.io and I will add new examples in the future.

3) I’m starting this blog/newsletter (https://next.waveguide.io), where I plan to write about UX and Technology Design. I will also give you updates when I add new examples to https://waveguide.io.

4) I hope you stay subscribed, but no hard feelings if you don’t ✌️

Just think about it. This website, your computer, your bed, your clothes, your apartment, the keys to your car, your car.

Knowing that everything went through a design process is liberating because it demystifies the path between “undesigned” and “designed.”

Of course, this doesn’t mean that everyone is a designer. At least not purposefully. Design is factual, but not everyone is a good designer, and that’s why people like me still have a job.

Good design is necessary because it enables creating of artifacts and concepts that can perform in an imperfect and chaotic world.

Usually, most products perform ideally in what designers call “happy paths,” a set of ideal conditions and scenarios required for a design to perform successfully. However, the most realistic “paths” are actually “unhappy paths.” It is because of these “unhappy paths” that many products fail in real-life conditions.

Unlike conventional designs, excellent designs can circumvent the existence of “unhappy” conditions and the influence of other low-performance designs. This requires the new design to lower its performance, and although this is not ideal, this is usually a trade-off that can help maximize the existing conditions.

This maximization is what I call Designed Degradation.

One great example of an excellent Designed Degradation that works in a highly constrained and poorly designed environment is the table in the picture below.

Take a couple of seconds to see the image and analyze what’s going on:

Still, confused? Look at the gap in the last third of the table. The one that makes it look like a different table:

Ok, so before I jump into the explanation, let me add some context first.

This table is located in a Chipotle restaurant in Pittsburgh, PA. Since I don’t cook, I spent an excessive amount of time analyzing this location during my time in Pittsburgh.

There are some important things to note about this restaurant:

• This Chipotle is at least 30% smaller than a traditional Chipotle.

• This Chipotle is located in a fast-growing area that has been rapidly adding residential buildings, businesses, and office spaces. The traffic in this Chipotle has been likely growing since it opened.

• Because of its location, the lease for this space is likely expensive. This means that any business that operates in the area needs to optimize the available real estate to serve guests still safely.

As you can see, this is a sub-optimal environment for a business that traditionally operates in spaces that are 30% larger. But because of its location, this business is expected to perform as well or even better than other similar businesses in less active areas.

How can you achieve that performance given the existing physical space constraints?

You can implement many techniques to enhance foot traffic in a physical business, but one that stands out in this restaurant is their use of bar tables.

The designer of this table understood that the problem to solve with this small location was finding a balance between the maximum amount of individual diner guests eating at the restaurant and the minimum amount of space used without sacrificing the perception of personal boundaries.

Adding the small gap in the last third of the table shows an exponential increase in the value that it provides given such a small space. A table that only can seat a single party automatically becomes a table that can seat two parties in any of the following arrangements:

• Party of 4 / Party of 2

• Party of 4 / Single Guest

• Party of 3 / Party of 2

• Party of 3 / Single Guest

• Party of 2 / Party of 2

• Single Guest / Single Guest

Although this affordance seems disruptive and perhaps ugly, it is the perfect example of a Designed Degradation that helps the user.

We can all agree that the ideal scenario has a restaurant that is 3o% larger and that could fit more tables. We can also agree that we all want to avoid that last third of the table as much as we can. But in a scenario where no other table is available, most people will use it. The world is wildly imperfect, and that’s where these cleverly Designed Degradations can help provide value to a final user.

Designed Degradations in Software

Designed Degradations play a unique role in the creation of good software user experiences. Although computers usually provide an experience that exceeds most analog human processes, there are a series of conditions in which computers can become more frustrating than helpful.

Usually, these conditions are the result of software running in low-performance machines, devices, or environments. Some common examples of sub-optimal conditions are a computer with low processing power, little memory, a low-resolution screen, or a bad internet connection.

Other less common conditions are poor light conditions, the environmental temperature that affects a device's computing performance, poorly designed peripherals, poor device form factors (handling, size, materials), and other similar intrinsic and extrinsic physical conditions.

Software Designers rarely, if ever, think about the existence of these conditions. For instance, modern software design rarely accounts for scenarios like random connectivity issues. Granted, most users will access the resource through a solid/stable connection, but those who don’t aren’t given a degraded option that could fit their particular situation.

However, designers are getting more conscious about some of these unavoidable scenarios and are starting to design mechanics that enable graceful degradations. Here is a list of standard and modern Designed Degradations in software:

• Poor battery life is an unavoidable condition of smartphones. In iOS, Apple provides a “Low Power Mode” that reduces power consumption by disabling certain non-critical features. This is a Designed Degradation that allows Apple to mitigate battery life issues.

• Netflix automatically adjusts the streaming bitrate based on things like bandwidth, latency, device, and location. Although most people would like to watch their content in sharp Full HD or 4K, Netflix degrades the streaming quality to avoid interruptions and preserve the overall quality. This Designed Degradation allows Netflix to provide its service to customers that are not in optimal streaming conditions.

• Facebook provides an offline tolerant experience by caching a large portion of the user timeline and allowing users to queue posts that automatically get uploaded when a connection is available. This is a Designed Degradation that enables a partial interaction without relying on an internet connection (instead of rendering the app useless).

Designed Degradations or Features?

Designed Degradations are functional. They give products, a mechanic to alternatively serve its final users. Because of this, sometimes Designed Degradations are seen as full-rounded features. However, from a product point of view is essential to avoid seeing them as marketable or baseline features.

These kinds of degradations exist to mitigate issues, not to make products more appealing.

This is a crucial distinction that can help product and design teams make critical decisions when prioritizing roadmaps and executing existing ideas. If the initial design process results in a product with substantial degradations in its foundation, you’re probably building the wrong product or building for the wrong market.

Final Thoughts

Designed Degradations are an essential concept to build and execute the right design strategies. Designers should be aware of the complex nature of implementing Designed Degradations and use them wisely to help their products succeed in conditions that are not optimal.

Designed Degradations can also behave as signals of work that are not perfectly aligned with a market or a product vision. Although they can help extend the capacity of products, they can also be clear indicators of mediocre solutions (especially when a product relies extensively on these degradations).

An excellent approach to evaluate a potential Designed Degradation is to stop and think for a minute: Would this help my users with their possible frustration, or would it accelerate their defeat? Although this exercise sounds like unnecessary rhetoric, you will be surprised that it would be the latter most of the time.

Note: Designed Degradation is a term that I coined for the sake of this article. If you’re more interested in this topic, here are some resources on related/homologous concepts.

• Fault Tolerance

• Fail-Safe

• Graceful Degradation

At first sight, there’s nothing special or interesting about the escalators or the general layout of the store. However, if you observe for a couple of minutes, you’ll start seeing some intriguing dynamics.

Since a picture is worth a thousand words, here is one:

So what’s going on here?

For starters, retail spaces are heavily optimized to increase foot traffic and sales. There’s no secret in that.

The interesting part is that usually, those patterns are subtle and hard to detect. In this case, Uniqlo was rather bold and made a statement with those escalators: “For every 2 customers in, one or less can go out”.

This is what I like to call a “Designed Inconvenience.” A type of user experience pattern (usually frustrating or not optimal) indirectly controls a user flow and impacts a decision-making process. Designed Inconveniences are usually created to favor a business rule or business-centric goal.

These escalators are a clear example of a Designed Inconvenience. Here are some perceived facts about them:

1. The two escalators on the sides handle the inbound foot traffic, while the escalator in the middle handles the outbound foot traffic. “2x in, 1x out. That’s my kind of math.”

2. When customers enter the store, they have to decide which escalator to take. Usually, they would take the least crowded one. Since the escalators are always moving constantly, there’s almost no congestion when taking an escalator up.

3. Inbound escalators are closer to other display areas of the retail space. This increases the chances of customers seeing products they might want to buy later.

4. Outbound foot traffic has only one escalator. Since that escalator sits between the two inbound escalators, the visibility of products while leaving is highly decreased. “If you’re leaving… leave soon”.

5. Unlike the inbound escalators, the outbound escalator would get some congestion. This usually pushes people to find alternative exits. “While you find another exit (if you do), go and buy another jacket.”

6. If you make the two most left (or two most right) escalators inbound and keep the right (or left) one as an outbound escalator, that would highly increase the traffic to that side of the store.

7. If you make all the escalators outbound, that will push all the inbound traffic to the mezzanines in the sides.

These escalators provide a great user experience for incoming customers and a not-so-great user experience for leaving customers. By doing this, Uniqlo is increasing their customer traffic and the time spent by each customer inside their store. Ultimately this would result in more sales.

Designed Inconveniences in Software

Designed Inconveniences are very common in software design. If you don’t believe me, try to log out from any of your favorite apps. You would find out that doing so it’s a little bit harder than what you expect.

This pattern became very popular when consumer technology companies realized that allowing users to log out was hurting their ability to push services and provide a more streamlined experience. So they buried the log-out button somewhere where you would rarely check.

However, Designed Inconveniences in software go way beyond hiding buttons or preferences. Here is a list of common and recent Designed Inconveniences in Mobile and Web Apps:

• Facebook launches a wide network notification when someone starts live streaming. This a Designed Inconvenience to promote and get traction for one of their newest features.

• YouTube has a default setting that auto-plays to the next related video without user intervention. This Designed Inconvenience increases user engagement and time spent on the website, which would ultimately translate into more time spent watching ads.

• Amazon tries to lock you in the checkout gateway once you hit that view. When trying to move back to the home (by clicking the navbar logo), you will be encouraged to stay and finalize the checkout or return to the cart where you would likely see related products and advertisements for credit cards with sign-on bonuses. This is a Designed Inconvenience to increase conversion rates and decrease cart abandonment.

• Spotify pauses an ad when you turn the volume down, and then it resumes the ad when you turn the volume back to an audible level. This is a Designed Inconvenience to preserve the integrity of the ads that partially finance Spotify’s business.

Designed Inconveniences vs. Deceptive UX Patterns

Designing against the user is something that you can’t teach. There’s no formal training or program in the world that would teach you how to create patterns that would degrade the final user experience of a product in favor of a for-profit goal. In fact, this is the opposite of modern design practices that are heavily influenced by user-centric approaches.

However, it’s important to note a big difference between a Designed Inconvenience and a Deceptive UX Pattern.

A Deceptive UX Pattern is an unethical method or mechanic that forces users through an unexpected path to later profit from them. They range from small UI distortions to complex ploys that trick users into thinking they would get something out of their performing process.

In contrast, a Designed Inconvenience is simply a design choice that can annoy users but rarely hurt them.

Companies like Facebook provide free services that depend on how well their monetized layer works. Sometimes to preserve the business viability of an idea, it’s necessary to expose users to unpleasant patterns and flows. Good UX Designers should always try to mitigate the UX impact of these patterns by bringing extra value in other product areas.

The best user experience is the one that balances business and user goals with subtle harmony.

Final Thoughts

you can’t teach the process of designing an “inconvenience” in a formal context, but it’s important to be always mindful of the necessary balance between business and user goals. A good and profitable user experience is better than an excellent user experience that is unprofitable.

If you are tasked to design an “inconvenience,” always try to find ways to mitigate its impact by being transparent with your users and allowing them to have a clear understanding of their usage alternatives (including the paid alternatives, like premium versions that remove the inconvenience).

Also, if you’re tasked to design a Deceptive UX Pattern, do yourself a favor and find a new job.

This joke is just a little anecdote about something that it’s a fact. Single-engine aircraft are not as reliable in emergencies because when their engines fail, the only real source of propulsion is effectively gone.

This scenario is one of the main reasons why the aircraft industry has avoided exploring any single-engine design for jet airliners. (I want to clarify that I’m referring exclusively to jet-propelled aircraft, not aircraft powered by propellers).

Although modern jet propulsion technologies can easily be tailored to generate enough thrust to lift a passenger jet airliner with a single-engine (which will result in massive maintenance cost savings), such kind of aircraft will eliminate one of the concepts that make air travel one of the safest forms of transportation: engine redundancy.

Two engines can increase the safety of the aircraft concerning engine propulsion availability and can help with backup emergency strategies like asymmetrical power (which can be essential support in a situation where hydraulic control is partially lost.)

The concept of redundancy, however, is not exclusive to aircraft. Many digital and technology products rely on particular redundancies to improve their final user experience.

These are what I call “Designed Redundancies.”

Designed Redundancies are usually a set of two (sometimes more) user flows or interface mechanics that allow a user to achieve the same result.

Designed Redundancies can be helpful with some troubling aspects of software design. For example, a Designed Redundancy can aid discoverability or be a sound fallback system to increase accessibility.

Some of the most common Designed Redundancies are the ones that exist with computer peripherals, in particular, mouse and keyboard. These two peripherals share a wide range of input functionality. In many cases, mouse left clicks and return keystrokes are interchangeable.

Also, the arrow system of a keyboard can often traverse and scroll a screen user interface the same way a mouse does.
But as beneficial and evident as they sound, Designed Redundancies can be very complicated and sometimes critically harmful to the user experience. Learning how to design useful and helpful redundancies can make a huge difference in solving severe design problems.

One example of poorly Designed Redundancies is the ones you can find in text processing software like MS Word.

MS Word comes with hundreds of layout and formatting options. Many of them are functionality duplicates that aim to address two different use cases with the same endpoint.

With the right scrutiny, this can be beneficial for the user since the software can adjust to different behaviors. However, in the MS Word case, most of these redundancies are the consequence of a malformed product backbone that increases the difficulty of deprecating old features.

This is a critical aspect when it comes to designing practical and useful redundancies. Many people try to defend the idea of concurrently keeping two competing features in a product since this can help existing users with change.
There’s a fear that by introducing sudden change, you will annoy and lose your existing customers (newsflash: if you’re changing is because there’s something wrong in the first place).

New features that are created to replace old ones should do exactly that. Despite the potential backlash from completely replacing a legacy feature, it is better to deal with and address this individually.

Keeping two redundant features for the sake of avoiding confrontation with your user base is counterintuitive. This approach usually creates confusion for new users and alienates existing ones.

Redundancy should never be a product delivery strategy. This is the most critical difference between a harmful redundancy and helpful Designed Redundancy. The former is created as a response to undesirable product evolution effects, while the latter is consciously designed to increase the performance and delightfulness of the product.

Designed Redundancies in Modern Technology

Designed Redundancies have been around for quite some time, but only in recent years became a prevalent user experience concept.

As modern technology has become more sophisticated, learning these technologies has become an equally complex task.

Many new technology products rely on well thought Designed Redundancies to increase their performance, ease of use, and overall satisfaction. Here is a list of Designed Redundancies examples in modern software and tech:

• When playing a song on Spotify (iPhone), you can skip the current song by either using the skip button or swiping the album covers.

• When browsing an Instagram feed, you can like a photo either using the dedicated ‘like’ button or by double-tapping the actual image.

• The Apple Watch allows you to scroll and navigate some screens by either touching the screen or turning/winding the watch crown.

• The Nintendo Switch has several form-factor redundancies that provide multiple modes and experiences with a single device. Nintendo relied on redundancies to create a console that adapts to an almost infinite amount of user conditions and behaviors from the symmetrically redundant joy-cons to the integrated device screen.

The Controversial Nature of Designed Redundancies

Designed Redundancies can be powerful mechanisms to enhance the speed, discoverability, and learnability of your products. In some cases (like in the Nintendo Switch case), they can be a core component of how your product delivers an experience.

However, redundancies are usually seen as a bad design paradigm. I can’t recall the number of times that I have been on a design review or critique in which someone presented a redundancy unsuccessfully.

Redundancies are seen as a contradiction to other more prominent paradigms like Simplicity. It’s easy to see how a not very well thought redundancy can make a product exponentially harder to understand and use.

But this shouldn’t discourage designers and product professionals from exploring and design useful redundancies. When created and used correctly, they can make a significant impact on the ultimate user experience.

Final Thoughts

The concept of Designed Redundancies can be a helpful resource to unblock design issues related to the general flow progression of a product. Although they are often misunderstood and often can be the source of confusion, they can become an essential differentiator of the product itself when designed mindfully and implemented correctly.

One excellent way to identify the difference between a harmful redundancy and helpful Designed Redundancy, it’s to determine its primary driver and how it fits contextually in a product.
If the redundancy feels and sounds like a band-aid solution or emerged from a non-user obsessed reason, the redundancy is likely harmful.

On the other hand, a positive Designed Redundancy will feel an integral part of the design contextually. By removing it or altering it, the product will likely lose its perceived performance/delightfulness.

Think about something like the wireless charging capabilities of the most recent iPhones and modern Android devices. Wireless charging is a redundant feature, but its addition improves the usability of the product and allows the product to be more adaptable to the user’s behaviors.

Not every Designed Redundancy needs to feel as crucial and vital as having two turbine engines in a jet airliner, but at the very least, they should feel useful enough to be noticed if they are gone.

Note: I’m not an aviation expert. Some of the aviation concepts may not be entirely accurate. If you want to learn more about redundancies in aviation, you can find more information here and here.

Imagine this situation.

You need to log in to a rarely used but essential online service.

You enter your email address and then type what you believe is the right password.

“Wrong Password or Email Address” says the website.

You try again with another possible password.

“Wrong Password or Email Address” says the website.

You try one more time with some other likely password.

“Wrong Password or Email Address” says the website.

You also get another condemning message.

“For your security, you’ll have one more attempt before your account is locked”

Alright. So clearly, you don’t remember this password, or maybe you did a typo in a previous attempt, but now you can’t retry any of those passwords because your account will get locked. So the only logical thing to do is to reset the password.

So you do that. You get an email that says, “Click Here to Reset Password.” That takes you to a page that prompts you to enter a new password, so you do that.

You can’t use a previously used password. Try another password.

Sigh…

Ok. So some facts about this particular situation. If you’re trying to access a service in a regulated industry where security is critical (like banking), this is pretty much an unavoidable scenario. At this point, you should be using a password manager anyway, although most people don’t (https://www.statista.com/forecasts/985146/using-password-managers-in-the-uk).

But what if this is not a security-critical service? Is locking an account good UX or bad UX?

One could argue that anything done in the spirit of security is good UX in essence. So although it’s frustrating for the customer to reset their password, they are being protected in a world where password leaks happen every day, and people still re-use their password across multiple services (https://www.zdnet.com/article/44-million-microsoft-users-reused-passwords-in-the-first-three-months-of-2019/).

But the reality is that this scenario is very frustrating. It feels like bad UX even though it’s 100% a user-error derivation.

But here is an alternative view of the problem. Most people will try for several minutes to log in to an account before they finally concede that they don’t know it and go through the process of resetting it. Why let users fail miserably multiple times when there’s a method available to regain account access?

When I think about it, I feel that giving a warning to the user that their account might be locked is just the equivalent to telling them, “Dude, you don’t know the password. Just reset it and stop being stubborn.”

You got to appreciate that subtle sincerity, the same way you understand when a friend tells you that you’re fucking up something (you might not like it, but it’s what you need to hear at that time).

So my opinion is that this is a good UX that feels bad. It’s like eating your vegetables when you’re a kid. They are good for you, but they taste terrible.

Regardless of what’s your opinion about this situation, I think we can all agree that passwords, in general, are a broken experience that never feels good. But for now, we can do at least some things to make it slightly better:

• If you’re a user, consider buying a password manager. They are not perfect. But they’re better than the default “password in your mind” experience.

• If you’re a developer, consider giving users alternative authentication methods like email magic links. Substack and Slack do it. Many more should.

For more random thoughts, follow me on Twitter: @whoisjuan.

Waveguide was a very popular repository of design patterns where I would collect and organize many examples of UX and UI design in the wild.

I decided to shut it down, keep my favorite content in the original domain and focus on writing stories and thoughts about User Experience Design in this Substack blog.

So this is what you see here. It’s called Waveguide Next because it’s what came after the original Waveguide, and I wanted to keep the brand and the lessons.

I hope you like the UX examples documented in waveguide.io and the stories, thoughts, and analyses posted here in Waveguide Next. I also plan to use Waveguide Next to tell people when new UX examples have been added to waveguide.io, so make sure to subscribe.

Thanks for all the support,

Juan (JJ)