Speed-Designing
Speed-designing is about making quick decisions

The process used to be simple and straightforward. Back in the late 90’s and early 2000’s if you wanted to make a website, you needed a Web Designer.

That basically meant you need a person who knows how to “make a website,” implying both design and code it. For complex websites in that era, you also needed a developer who coded a back-end and databases to make it more robust.

The early days of the internet were all about experimentation. Everything was new and exciting, and there weren’t really a lot of resources to learn from. People made mistakes. Then learned from them. Consider this an early-stage internet research methods.

Build. Test. Update.

Sounds familiar?

Build-Trust-Update

Then UX came along

Even though the term User Experience has been around for a while now, it went more mainstream around 2007–2009. UX’ers became the most sought after employees. The notion was that we weren’t doing UX before (false), and now with proper UX, we will make our products skyrocket to never before seen revenues.

The UX process was new and exciting too. Back in the early days of the web, there was no place for colorful post-its, long workshops about how the users *feel* and complex personas with backstories ranging all the way to their persona-grandparents.

CEOs almost unanimously acknowledged that this is the “new normal,” and to deliver a truly remarkable (in terms of sales) product, we need great UX. And to have great UX, we first need to jump through many hoops that aren’t even really considered “design.”

Many people who don’t do design decided to abuse that opportunity. All you had to do was to be a swift talker, learn some jargon, and you could be one of those “meeting room UXers.” They don’t design, but instead, they “ideate.” They use hard to understand terminology to mask that there’s very little behind it. They shrug when asked to sketch anything out, saying that drawing actual lines is for kids. They’re here for a higher purpose.

They also gave UX a bad name and a bad rep with clients. Many of them started noticing a trend of overblown budgets on things that weren’t even that relevant to the product. Additional “processes” were added when they were not necessary to siphon more and more money from clients.

That lasted for almost a decade

But at some point, two paths converged. One was the fact that by then (the early 2010s), most clients were also *users* of technology and the fact that they felt like the UX industry is cheating them. Why do we need to make three different fidelities of the design instead of two? Why do we need personas when we have a clearly defined and market-tested target group? Do we need to diagram the checkout process for e-commerce when there are already good patterns?

But the main reason, the first one is that by using modern technology (apps and modern websites) for over a decade, regular people (non-users) started seeing the patterns. They understood the good practices. They knew what made them frustrated in an onboarding flow or how to make a registration screen convince you to uninstall a product.

Clients Became Designers
Clients became designers so that they can talk to designers better. The communication is now two-way.

They subconsciously became designers too.

And knowing more of the rules and good patterns led them, even more, to start experimenting themselves instead of paying a premium for a *proper UX team*.

Lucky for them, around that time, design tools had their next big revolution with the release of Sketch, which transformed and democratized the way people design. Suddenly you had an app with a UI similar to PowerPoint (which you already knew), and you can use it to mock up a wireframe of what you want in your product.

Combine that with your understanding of what’s good and what’s bad from other apps, and you have yourself a “designer.”

Around 2014 we started seeing previously non-technical customers making the first sets of low-fidelity wireframes themselves. Their marketing teams did market research and focus groups (instead of outsourcing it to the UX people).

It was back to the value of the product being the most important thing.

Since 2014 the process has accelerated, and the quality of customer prepared initial UX work became better and better. Both their own internal research and even wireframes were often just as good as the ones prepared by professionals for a hefty sum.

In most cases, as a design+dev agency, we simply made some tweaks and did a few short workshops with the clients to make sure they understand what they’ve created. Then created a dedicated, beautiful UI and coded the result.

It got fast.

The process got faster and more agile. Only a handful of companies wanted “the whole UX process,” including 4 UXers at a meeting talking about user feelings for hours and billing per person per hour of their time.

Most clients understand the need for research, making informed decisions, and “good design.” But there are now enough good patterns and practices that it’s become more of recycling of ideas in a new way with the UI and micro-interactions becoming the biggest differentiators.

Don’t get me wrong, UX practices are necessary to help a product that already has value. But if the product is useless and people don’t want it, no amount of UX will convince them otherwise.

Avoid Bad UX

The same goes the other direction, too — if your value is through the roof, your users will ignore all the horrible UX flaws just to have a taste. There are many extremely BAD products out there, but delivering enough value that people use them and “like” them anyway. Even if they’re a lot harder and more cumbersome to use.

Speed-designing

In the last year, with the world going into lockdown mode, we started seeing a trend of creating very fast, iterative, super-high-fidelity designs and quickly testing them with the users.

Companies simply have less money for the entire process, and in many cases, it’s faster to mock up a beautiful product with the heuristic-based flow, then test it on the users, make modifications and test again.

I started doing live speed designing at our events in Sopot, Poland, in 2019, and people loved how you can take an existing product and apply some of the existing “good patterns” to fix both the IA and the UI of it. And all of it in a little over an hour, live in front of an audience.

Example of a Speed Redesign Exercise done live with an audience — Timelapse

How to speed redesign

First of all, you need at least a dozen completed design projects (including high-fidelity UI work) to consider trying it.

The next step is to identify the problems with the product. Note out the ones you see at first glance contrast, bad information structure, confusing groups, and hierarchy. Don’t worry if you won’t get them all, that’s not the point here.

Then you start designing the new version by touching on all the pain points you outlined in the first step. The idea is to work as quickly as you can, letting your intuition guide your first moves. That improves the brain — eye — hand coordination, and after a while, our brain starts to choose the best possible option instinctively.

Of course, you’ll make mistakes working that way. That’s normal. After a while, however, you’ll make less and less of them. And in the final step, you iterate on your changes and improvements. But by fixing the obvious problems first (readability, hierarchy, grid, and basic IA), you can spot additional issues a lot easier.

It’s a proven way to stand out from the crowd and convince clients to trust you. After all, you’re valuing their time because you can deliver something to them much quicker. And that can lead to you adjusting your hourly rates to fit that.

Michal Malewicz

Michal Malewicz

I’m a designer with over 22 years of experience, working with both startups and Fortune 500 companies. Check out my books: www.designingui.com, www.frontendunicorn.com, www.thatstartupbook.com

Previous ArticleNext Article

Leave a Reply

Your email address will not be published. Required fields are marked *