Imagine the following: You are working on an accounting app and are given the task of enhancing the Activity page, which has a table that is used to track user actions. You have been asked to add a search, more filtering options, and additional columns of data, or whatever else is needed to make sure administrators and other users can easily find what they need.
Evaluating the Current State
Right now, the appearance of the table is pretty rough. It includes sorting and filtering mechanisms, but they are not modern or user-friendly. After evaluating other parts of the app, you notice that other pages have different table and filter styles, but, frankly, all of them look pretty terrible.
Making Improvements
You are excited to spruce things up and create a modern, useful page. You are going to delight the hell out of those administrators! You get to work, crafting a page that follows modern standards. You have included a simple search, and filters elegantly incorporated into sortable table headers.
The team is excited about this project; this redesigned table is more powerful, usable, readable, and scalable. It is so much better than the old one!
Not So Fast
Weeks turn into months and the project drags on. It needs to be released, and everyone has to move on to new projects, so the team scrambles. The project ends in an unsatisfactory state that is hardly good enough for users, and full of glitches and technical debt.
Meanwhile…
While this is happening, a new designer has joined the team and is tasked with designing another new page with another table.
Like you, the designer looks around in the application and finds various tables and filters that are outdated and not very user friendly. The updated Activity page isn’t live yet, and their project team is separate from yours, so they don’t know about your project, and vice versa. Like you, they decide to design a new and improved table. They use a modern, spacious, minimal design.
This design is attractive, and a great improvement!
But after spending more time at the company, the team realizes it can’t become a template for other pages. It is not on brand and does not meet the company’s accessibility standards. The new project team was not aware of either of these factors. This project was low on the company’s radar, so it was completed despite these shortcomings.
Complications Arise
Fast forward another few months and a new filter needs to be added to all of the tables. With multiple table and filter styles, there is no simple or consistent way to introduce the new filter. Each table needs to be considered separately, and the filter is added in multiple ways. This is time-consuming and confusing for everyone involved. Everyone starts to realize that by trying to make each page better, they have created a mess.
More Complications
Fast forward another few months and a new table is needed again. This time, the team thinks it through more carefully before introducing another new design. Your redesigned table still isn’t working quite right, and there isn’t time to fix it. No one wants to go back to the old style, so another new version is created which uses the old components but makes them look similar to the new version.
There are now a handful of versions of tables and filters, each with its own nuances and issues.
With each new project, the problem will only get worse.
And it isn’t just designers that are affected. Developers end up with different versions of components that become more and more fragile and hard to maintain. QA Engineers don’t know which versions are right or wrong, leading to lengthy and messy conversation threads trying to figure out what to test for and how to keep track of it. Users are left with pages that all look and function differently, leading to confusion, frustration, and lack of trust in the application.
How can we avoid this trap? How can we work as an agile team, making incremental improvements over time, without actually making things exponentially worse?
How to make a change that is actually an improvement
Teams often like to move fast and break things, and it’s never long before it starts to catch up. Before you hit the ground running to create something new or improved, stop and ask: Are existing patterns good enough already?
I get it; we want to take pride in our work and create a better experience in our corner of the software. It feels wrong to leave the same old, outdated patterns in place. But counterintuitively, a shortsighted improvement right now most often makes things much worse in the long run.
It’s important to see how your work fits into the larger experience of the application. Don’t stay narrowly focused on just one page. Consider the following:
- How does this page fit in with the rest of the app?
What other pages use similar components? How is this page used in the application as a whole? - How are users impacted?
Will this be a major or minor improvement for users? Might it become a source of confusion or frustration because of unwanted change and inconsistency with other areas of the app? - How is the business impacted?
If this page is improved, what is the cost, the impact, and risk involved? Investment in this work should yield strong returns. - How is development impacted?
What technical constraints are there to consider? Does this change make sense from the development team’s perspective? Maybe this fits right in with a refactor they’ve been wanting to complete, or maybe this throws a big wrench in the system, and they don’t think this is the right time to do this. - What other upcoming changes might be impacted?
Are there any other projects involving these components? Are there other projects involving this page? Find out who else might be making related changes, and make sure to coordinate with them. - What is the plan to roll out these changes?
If you discover 5 other pages that need to be updated, will you start with one page, and change the rest later? Will you change all of them at once? Will you save the redesign for a later date when there is more time to implement it properly? Whatever the plan, make sure it is realistic and has buy-in from all parties involved. - How will these plans be documented, communicated, and completed?
Even if your team agrees on a plan, it will be forgotten as soon as your current project is done and everyone has moved on to something else. These plans must be documented, communicated, and followed up on. Coordinate with your team to make sure this happens.
What seems simple on the surface is often far more complex once you dig a little deeper. If you are moving forward with a change, it is important to consider these complexities now instead of waiting until later when they become large problems that are much harder to solve.
The best change is often the smallest one.
The next time you step into a project and wonder why everything is a mess, understand that there were probably many well-meaning teams just trying to make something better, but instead incrementally adding to a mess that grew exponentially worse.
And the next time you want to make something better, remember that keeping something consistent and “good enough” is oftentimes better than, well, trying to make it better. Until you can answer the questions above, resist the urge to improve a page, or your improvement will probably make things worse.