By far, one of the more frequent requests we explore with clients is to redesign something that exists rather than create something new. My back-of-the-envelope calculation sets the ratio at 10 to 1 of requests for app or website redesign services over creating something from scratch. Yet many organizations don’t consciously differentiate between designing something new and redesigning something that already exists.
In fact, many requests to design something from scratch are actually incognito redesign efforts. For example, a very likely redesign request sounds something like, “Our competition launched an app and they’re gaining market share. We have a better idea that will dwarf their efforts.” It is very likely their idea is to build a better version of an application, website, or system rather than a new and unique product.
Design students are typically taught how to create something from scratch. But more often than not, professional designers are asked to take a thing that’s not performing well and make it better. For example, during a tour of Think Company that we gave to a group of design students, we asked them about current projects. One of the students described an exercise to design and build a web page with a calendar on it. That seemed like a great, rudimentary exploration of design and coding practice with many layers of complex interaction. We are all exposed to several different calendar patterns every single day in our digital lives and have many preconceived notions about how they should act and work. The fundamental skills and process of designing from scratch are vital, but the process of redesigning a website, app, or tool requires additional perspective.
A few common archetypes of a redesign project:
- Digital Product or website revamp: An existing product or process is underperforming, needs to be updated, or does not stand up well to competitors
- Migration: An existing product, system, or website is being migrated to a new platform
- Process improvement: A collection of processes and tools are being made more efficient
- Design System creation: The vast majority of design system projects are redesign projects at their core. An organization has a collection of products, sites, other human experiences, and processes that need to be unified
- Revolutionizing an industry: Competitors are doing something better and an organization has a brand new idea to flip the situation
Yes, Redesign Can be Revolutionary
Perhaps that last bullet caught you by surprise. After all, the client is saying, “brand new idea”—why isn’t that a design-from-scratch project? The fact of the matter is that designing something to compete with another product involves all the same activities described below.
If “revolutionizing an industry” is too radical to get attention and funding, you could call it “leapfrogging the competition.” Consider Tesla. While they revolutionized the approach to electric cars and automobile manufacturing, they were built on a strong understanding of what the competition was doing. Many of the fundamental elements of a car remain in a Tesla, but they’ve been reimagined.
One caveat with revolutionary work is that you usually end up building something from scratch, so your team will not be distracted by the backlog of things to fix along the way. However, they will be distracted by the difficult challenge of building and launching an MVP.
Absolutely unique, brand new ideas are rare, and we shouldn’t be ashamed if our amazing idea is approached as an improvement to something else. Heck, truly unique ideas can sit on shelves for a long time before someone figures out what to do with them, like the Post-It note. Personally, I’d rather have my great ideas launched sooner.
Below are the stages of approaching a redesign project for a product, app, website, service, or idea that already exists, but needs to be reimagined.
The 6 Activities of the Redesign Process
1. Define the Problem
Your initial problem definition will evolve as you journey through this process, but you need to start somewhere. Saying, “Our competitors have an app” is not a definition of a business need, it’s simply a statement of fact. Your competitors may have invested hundreds of thousands of dollars to build a digital tumbleweed. Why follow them down that silly path?
There are many great formats to define a problem. At Think Company, we often frame problems in the format of:
We want to [the goal] so that [the outcome] because [the challenge].
We know we have succeeded when [the measurable impact].
An important aspect of defining the problem is asking yourself the question, “How will we know that this problem is being addressed?” This helps set your measurement strategy. For any business pursuit, it’s important to define measures of success for that pursuit. In the world of redesign projects, there are two important questions to ask at the beginning of the redesign process: “What are we currently measuring?” and “How will we know we are successful in this endeavor?”
The answers to these questions will likely evolve throughout the life of the project, but it’s important to continue asking these questions and being sure you’re following a metric-based approach.
2. Diagnose What is Needed
While you’re gathering your inventory (see below), you should also begin to uncover where the challenges lie.
Record What You Know Needs to Be Fixed
First things first: most redesign work is paired with an acute need to fix things that are desperately in need of repair. Cynics try to avoid this task with the analogy of “you can’t change the tires while the car is moving.” That’s a cute metaphor, but this is 2020 and you’re not redesigning a bus. If you were redesigning a bus, you wouldn’t be redesigning the same freakin’ bus that’s hurtling down the highway full of passengers. You’d be working on a bus that’s safe in a garage somewhere. So, let’s get out of metaphor land.
Of course you can fix egregious issues while you’re doing the deeper investigation work. The first thing to do is to open up a fresh backlog where the team can record immediate fixes that need little or no further investigation to be addressed. We’ll talk more about this in the inventory stage, but even before you open up your first stakeholder interview, you should be prepared to record their laundry list of known, fixable things. Trust me, they’ll let you know about them.
Discover What is Still Unknown
Now it’s time to start developing your research strategy. What this looks like will vary depending on the redesign task. Your stakeholders will be passionate about ideas that they’ve formed. Listen to their ideas, dig into the core hypotheses around those ideas, and rapidly test them in the field in the most efficient way. And while you’re out there doing field research, start to dig into the deeper, more hidden issues—those known unknowns and unknown unknowns.
Here’s what that may look like in practice:
Your stakeholder asks you to redesign their shopping site while it is migrated to a new ecommerce platform. The first thing she points out is that the shopping cart has major accessibility issues and she hands you an accessibility audit done by another consultant last month. She is adamant that the next big problem is that the current IA of the site does not reflect the mental models of the modern shopper. Their customer care center often fields requests that can be summarized as, “I can’t find a thing I know you sell.”
First, you assure her you’ll prioritize all the accessibility issues to the top of the backlog and get a sprint team to start knocking them out. Boom: immediate progress.
Next, you recommend doing an inventory of all the content, a deep dive into analytics, a heuristic analysis of shopping workflows, and some card sorting exercises with current customers and non-customers. After each card sorting exercise, you do some goal-based shopping exercises to see if there are any other underlying issues with the site. That’s a win-win. You can explore her IA hypotheses while digging for other challenges.
The ultimate outcome of this step is a solid foundation of insights. Insights can take many forms. One really effective form is the [ideal] but [tension] form described in Kiley Meehan’s Bite-Sized UX post.
As the research is going on, you are hopefully finding, counting, and naming things.
3. Take an Inventory of What Exists
At its core, an inventory is finding, counting, and naming what already exists. In many instances, the bulk of an inventory can be done mechanically. This phase is important to help gauge the volume and breadth of the work ahead.
The type of inventories you take depend on the design tasks at hand:
- Redesigning anything at all? Run your software or website through a well-known accessibility assessment tool (like WAVE or aXe) and document every single accessibility issue you encounter.
- Redesigning a website? Point spiders at it or run reports from your CMS. Collect all of your identity and governance documentation.
- Building a Design System? Gather all of your UI documentation, pattern libraries, code repositories, product screens, and design and development processes.
- Redesigning a service? Track all of the touchpoints of the human journey throughout that service.
- Building a better mousetrap? Look at the entire competitive landscape to find all the mousetraps that exist and document what makes them tick. Conduct comparative research to see if there are products that achieve a similar goal in a different way.
Another important element to an inventory is reviewing and assessing anything in the existing platform’s backlog. Every organization records this differently. In an ideal scenario, the backlog is recorded in a tool like Jira or some other ticketing system. In other scenarios, the backlog can be in the minds of the stakeholders and creators of the platform. Heck, it may even be a collection of post-it-notes stuck to someone’s monitor. Regardless of where this list is, it’s a valuable resource to identify immediate fixes to start working on while additional discovery work is being done.
4. Conduct an Audit
Often the terms “inventory” and “audit” are interchanged, but they are distinct exercises. While an inventory is about counting and naming things, an audit is about assessing those things against agreed-upon criteria.
It’s important to be patient when starting your audit. Folks often jump to the audit task quickly without getting everything else ready. The challenge with doing that is you’re not sure if you’ve counted and named everything and you’re never sure what you’re auditing your inventory against.
Prior to starting the audit work, come to agreement on two things:
- What criteria you will evaluate your inventory against
- What constitutes a representative sample of the material in the inventory
If you have a tiny collection of design patterns, sure—audit the whole thing. If you have a massive CRM with thousands of articles and videos, put together a plan on how to capture a representative sample size.
Once you’ve come to agreement with your team on the criteria and sampling, hammer away at your inventory.
The final outcome of an audit is a plan for governing future materials and creating new materials. You will be able to lay out a comprehensive migration plan (see below) of any existing materials with details on how to transform, deprecate, and move materials into your new platform.
5. Design, Build, Validate
We don’t need to get deep into what the design > evaluate > refine process looks like, that’s for any article written on the design process.
Throughout the redesign process, though, your team has been maintaining that backlog and possibly working on it. These issues can include things such as known bugs, design flaws that violate well-known design or coding practices, known accessibility issues, and new features the team has been exploring. Once you get to this stage, with your backlog in full swing, your design, build, and validation work should fall right into place.
But your work is not yet done.
All too often, migrating between two platforms during a redesign effort is an afterthought, yet it is the most critical part of the redesign effort.
You need to ensure that existing information (content, data, design patterns, user accounts, etc.) is effectively and efficiently moved from the old platform to the new. This is not a trivial task. Some common questions that a well-formed migration plan address are:
- How do we preserve all of our SEO juice during this migration?
- How do we transform existing content into this more sophisticated content model?
- How do we edit existing content to match new editorial guidelines?
- What is our plan for the retirement of old content?
- What is our redirection strategy for retired pages?
- How will user accounts be migrated into the new system?
- How do we preserve our analytics?
- What will our new reports look like?
- How do we orient the users to the new platform?
- How do we adapt all of our old design patterns to this new design system?
A comprehensive migration strategy will address all of these questions and more, but here’s the kicker: If you cut corners in the beginning, and didn’t take an inventory of everything, there is no way to know how much stuff you will need to migrate. If you had treated this work as a simple design effort rather than a redesign effort, migration becomes a wildly unknown effort. When you encounter it, you’ll have to do the inventory anyway—and that puts you several steps behind, throws you off schedule, and, since you’ve already spent most of your budget, you’re likely digging deep into your pockets just to get the work done.
A Website, App, Product, or Process Redesign Can Yield Big Results
While the notion of redesigning something doesn’t feel as prestigious as developing a brand new idea, it’s all about how you position it. A product team can approach a redesign project with the motivation to do more than just spruce something up. Some of the most successful, innovative brands were founded on the practice of redesigning products that had no traction. We already talked about Tesla, but consider Apple. They are rarely the first to market on personal computers, MP3 players, or smartphones, but they use what the market is telling them to introduce better versions of those products and consistently iterate on them.
Redesigning something—and giving teams some perspective on the nuances of this process—can change your industry.