So, part two of my debt series is about conceptual debt, or product design debt, or UX debt. This is a subset of technical debt, but specifically related to the design of the product, or the UX. See part one here
Most iterative development cycles form a minimal viable product, which is then improved upon with each release. We experiment with design and features, and then either add or change based on feedback. The issue of course is if the feature is successful, then design and ux refactoring rarely happens – we move onto the next feature.
The prime example of this is the crowded homepage, especially for online stores, in my opinion. Navigation gets more complex as more lines, sales, and categories are added, but, if it’s an established site, changing the navigation may be detrimental to the traffic that goes through to various parts of the site.
Offers, signups, social media blocks are all added to the homepage, and also services like optimzely allow users to easily do A/B testing by changing various parts of the site (A/B testing is where you make a change to a site, but only have the change show to a certain percentage of users (you can target users from devices, or certain browsers, or just at random), then compare the results of the change).
I separate technical debt from UX debt as UX debt is sometimes harder to quantify – it doesn’t necessarily affect performance or functionality like technical debt might – or might not be as visible (slightly clumsy user journey vs. a small bug in a feature). That doesn’t mean it’s not as important, it’s just different, and requires a different approach.
Fixing UX debt may also be a large change that may be too scary or time-consuming for the stakeholders to be able to stomach, and so it stays as it is, of only gets fixed slightly. Refactoring code to reduce the technical debt I mentioned last week does not (or should not) affect the functionality.
A blog post I’ll link uses Vegas as an example of product design debt – there’s so much stuff that’s been built close to other existing things to get more attention, or add more features that it becomes a confusing and confused looking mess. And fixing that is not going to happen.
So, how do you avoid, or minimise this type of debt?
Firstly, not going into it in the first place, or going into it with a plan. This is easier said than done, obviously, but careful planning and future-proofing will take time, but also save time.
This really changes depending on whether you’re in house, or a SAAS company, or an agency. I’ve worked in both, but I have more experience in agency work, and its a different kettle of fish.
As a team, you need to interact with the stakeholders to get their overall vision, their brand, what they want from their product and what their users want. From there you can build up ideas of the product, design features and the UX, and start building.
Once you start building you need to refactor as you go, and this includes the UX if needed. If you add a new feature that needs to go in the menu and on the homepage, you and the stakeholders might need to consider that feature in the wider scale of the project.
UX is a little harder on an agency project, because you might have two layers of separation from the users – there’s the team building the product, the stakeholders, then the users. Sometimes the stakeholders are users, but often there are users that don’t interact with the build team, so a lot of debt might be unintentional, and inadvertent, which is why regular refactoring is needed.
Again, there’s no way to avoid debt, shit happens, clients change their minds, features require different user paths on reflection. You need to build in time to refactor this into your sprints, just like you would build in time to refactor code.