I recently started a project with a client who was managing a successful suite of web & mobile applications, all under the umbrella of their digital brand guidelines. This was a small team and resources were tight, so managing that many apps over multiple swimlanes was threatening to create a monster soon - a monster I refer to as the Franken-Brand.

What's a Franken-Brand?

Franken-brands happen when apps are built next to apps, and no high-level overview of the brand as a whole has happened in an extended amount of time. This can happen for many reasons. Most commonly because guidelines are implemented faster than they're audited, because we don't know what we don't know when we initially write them. Another reason this can happen is that resourcing is so limited that only one or two people are overseeing an entire suite of applications, so their expertise is only applied on the surface. App-specific requirements are applied on top of general guidelines, and never make it into the official document. This "if it ain't broke, don't fix it" environment is classic in a small team.

What is a Franken-App?

Similarly, Franken-apps happen when features are built on top of features, but high-level overview of the full user experience is neglected. This usually happens when there are multiple stakeholders spread across an application and dedicated product pros are spread too thin. Sometimes, depending on the workflow, initial feature specifications are written side-by-side instead of consecutively, so inconsistencies are naturally created. We work in a field where there are a lot more combinations of "right" answers than "wrong" answers, so two teams may come to entirely reasonable translations of a guideline, but they don't match.

What's to be done about it?

Well, in the case of my client, we're going to form an angry mob - kinda. This week, I launched a full audit of all states of all screens of all apps, after which the entire suite will be reviewed by myself and some other contracted UX pros. Bringing in new talents that I've not worked with before exposes us to other areas of expertise, and ensures that we remove bias from the redesign process. Commonalities between features will be identified and brought into harmony as we develop short-term and long-term specs for change.

After that, the ecosystem-wide guidelines will be updated, and the new version will be used going forward until the day when, inevitably, it's time to review again.

Have a tip on how to avoid the Franken-Brand syndrome? Tweet me @ashleymarinep!