217. Doing a UX/API Redesign? Here are 12 Rules of Thumb

Redesigning the UX or API of a product seems to always be in the plans. No product is perfect and customer feedback abounds. Some things you might think of if you embark on such a journey.

Some of the influences and redesigns from my own experience that contributed to the perspectives shared in this post. The links at the bottom tell the stories behind these. This includes the redesign of Office 2003, 2007, and Windows 8.

Considering a major UX redesign? Here are a dozen rules of thumb to consider. You might be thinking that your UX, web or mobile, has become too confusing, too difficult to navigate, or too disorganized after addition of new features and capabilities. You might think a refactoring or reorganization might help. This also applies to APIs.

I wrote these in a “hardcore software” tone because major redesigns require a lot of guts and effort to see them through. So I made them seem like absolute rules. YMMV. Context matters.

Consider:

1. A redesign should only be undertaken if you believe that the number of totally new customers to your product/platform are greater than the number of existing customers who already know your UX.

2. Always remember that if you think you are making things 10-15% better, faster, more streamlined you are in reality making things 100% different for existing users. Note your most vocal power users will point out every single thing that got slower. Everyone else will just suffer in silence.

3. If you’re a big established company, the chances of needing a major redesign are slim. The same holds for any internal facing tooling, perhaps even more strongly. See first point unless you really see the upside in new users. Big companies will almost certainly convince themselves of some form of cost savings, but that savings will be consumed by the customer support org, distracted account managers, retraining employees, or monitoring reddit forums for haters. The bigger you are the more ergs will be spent on any changes. If you’re still a young company, there’s a good chance the UX is messy. There’s a better chance that spending limited energy will be less of an unlock than expanding the capabilities of your product. New to market solutions are always hammered by incumbents as being “difficult” to use because they are new products approaching things in new ways, but don’t interpret their desperation as a need to spend resources on high opportunity cost. That’s a trap.

4. Any redesign should start from enumerating the benefits as seen from a customer perspective. If you think “get things done faster” or “access new functionality” then be able to measure those. Once you know the benefits, then you can develop the framework—a bulleted list of perhaps 3 no more than 5—pillars of the design. You’ll want to run every change through this framework and measure against the benefits the whole time.

5. A new design should not move the same functionality around, but rather it should be able to present new capabilities as well as old capabilities at a higher level of abstraction. This follows from the fact that you’re embarking on this project because the product does much more than it used to. Products get easier to use when they operate at higher levels of abstraction.

6. Do not add a compatibility mode. If you have such a mode then you will come to regret it over time because everything will need two entry points and every test scenario will need to consider two paths. Additionally every future innovation will need to figure out where to fit in the old model. And you will never be able to turn it off. Yes it is enormously tempting. In the end it signals a lack of conviction or worse a lack of utility.

7. Know the number of clicks, taps, keystrokes for the most frequently used commands and verify that none of them take more actions to get to.

8. A major 🚩for any UX change is that you have to provide an overlay or “first run” experience explaining where things moved because it isn’t readily apparent where to find something. It is 2024 and no one wants to be interrupted for a “tutorial” on using your product.

9. Resist surface level design changes that are entirely presentation in products or naming conventions/module organizations in APIs. These churn people with no benefit. In particular they break a long tail of slide decks, how-to posts, videos, and internal training manuals. Graphical changes are enticing for marketing, branding, and to “freshen things up” but ultimately are not a good engineering tradeoff. It screams “we had no other ideas.”

10. Regardless of scale, if your product is used across different languages and regions, then spend the time on major markets. Quite frequently redesigns introduce new terms and new presentations that don’t work as well outside the market where the product is developed. For any product, any redesign needs to validate the design for those customers that use various first and third party accessibility aids. This is especially critical if the new design creates a new (or “non-standard”) metaphor, UI control, or especially anything not represented in the platform framework.

11. It is very tempting to want to keep a design secret because it can make for an exciting rollout. That pretty much works only if you’re Apple. If you’re a service and you’ll be running test flights then word will get out anyway, especially before you’re finished. You don’t want to be defending unfinished work. The best bet is to refer to your principles and begin articulating the details of the design before people know, perhaps if you’re a large effort in a private forum of highly engaged customers. You have to consider their feedback if you do that.

12. Finally, almost every redesign goes through two major panic attacks. The first is at some point during development portions of the team, usually not the team doing the design but other parts (like a backend team) get wound up that it isn’t working. Second and later, some set of the first people to see the design in action will go crazy hating. That’s because it just landed on them and they know the product and their investment has now been “erased”—this is a “moved the cheese” moment for your most engaged customers. This is part of the process. If you developed measures of success as above and principles as to why and how you’re doing the work, these should sustain you through these moments. If you panic and substantially redesign the redesign it is almost certainly the case that the project will go off the rails.

Some personal trials and tribulations:

Trying to be clever about reducing surface area of UX to avoid that bloated feeling in Office. https://hardcoresoftware.learningbyshipping.com/p/052-alleviating-bloatware-first-attempt

Redesigning the most used and most complex productivity tools to unlock features, expand to users Microsoft was losing to Google, and avoid commoditization (and compatibility mode). Begin here, read 7 posts, https://hardcoresoftware.learningbyshipping.com/p/076-chasing-the-low-end-product

Oh, and the Start menu. https://hardcoresoftware.learningbyshipping.com/p/102-experience (and also the Epilogue)

#####