# Improving User Experience by Doing the Big Refactor

DevFeed: [Improving User Experience by Doing the Big Refactor](<https://devfeed.tech/articles/improving-user-experience-by-doing-the-big-refactor-19835.md>)

Original publisher: [Read original article](<https://tech.gc.com/how-we-improved-user-experience-by-doing-the-big-refactor/>)

Author: GameChanger

Published: 2021-05-13T17:33:18Z

Content type: article

Language: en

Sources: [GameChanger](<https://devfeed.tech/sources/gamechanger.md>)

Topics: [User Experience](<https://devfeed.tech/topics/user-experience.md>), [App](<https://devfeed.tech/topics/app.md>), [data](<https://devfeed.tech/topics/data.md>), [Database](<https://devfeed.tech/topics/database.md>)

Tags: [analysis](<https://devfeed.tech/tags/analysis.md>), [app](<https://devfeed.tech/tags/app.md>), [blog-post](<https://devfeed.tech/tags/blog-post.md>), [complexity](<https://devfeed.tech/tags/complexity.md>), [cost](<https://devfeed.tech/tags/cost.md>), [customers](<https://devfeed.tech/tags/customers.md>), [data](<https://devfeed.tech/tags/data.md>), [database](<https://devfeed.tech/tags/database.md>), [launch](<https://devfeed.tech/tags/launch.md>), [project](<https://devfeed.tech/tags/project.md>), [refactor](<https://devfeed.tech/tags/refactor.md>), [software](<https://devfeed.tech/tags/software.md>), [technical](<https://devfeed.tech/tags/technical.md>), [tests](<https://devfeed.tech/tags/tests.md>), [user-experience](<https://devfeed.tech/tags/user-experience.md>), [ux](<https://devfeed.tech/tags/ux.md>)

## AI overview

The article describes GameChanger's decision to undertake a major refactor of its data model. The project replaced a foundational database entity with new entities to address user confusion and editing restrictions in Team Manager, with the goal of improving the user experience.

## Source excerpt

In a long lived and complex application, there often comes a time when some early decisions end up becoming constraints that are difficult or impossible to overcome. At some point in the lifespan of the software, you may be faced with a choice -- do the Big Refactor, or find ways to work around the problems. More often than not, the latter route is taken. When you have a lot of immediate priorities, it's difficult to justify spending a lot of time on a big and potentially risky project. Sometimes however, the benefits of doing the big refactor greatly outweigh the drawbacks. It takes a cost-benefit analysis specific to your app to determine if that is the case. And recently at GameChanger, the big refactor was worth it, so we did it! This blog post is about how we at GameChanger successfully executed a huge overhaul to our data model. We removed a foundational database entity, person, upon which almost every part of our system relied in some way, and replaced it with new entities which enabled the user experience that we knew our customers expected. We'll take a look at what user-facing problem we were addressing and the high level adjustment to our data model. We'll also talk about how we approached such a large project tactically, some of the interesting technical problems we solved along the way, and the benefits we're reaping a couple months out from shipping. The Problem 🧩 For a long time, one of our most common complaints from users of Team Manager was the complexity around who can edit players and what information they could edit. The root of the complexity was this: a player could be created without an email address, but, once a player was attached to an email address, a user could not edit that player's information, like first name or last name, independently of another team. A player's name and their relationships to other users would carry over from team to team. And that meant in order to avoid situations where a coach on one team could make edits to a pl