Winchester-housing: what is it and how to avoid it
“Enterprise disease”. Its causes, symptoms, prognosis and treatments
Any UXD who’s been tasked with designing a new feature for a legacy internal tool or enterprise software has probably encountered an interface like the one pictured above. 5+ rows of tabs, dropdowns galore, menus stacked upon menus, radically different interaction patterns depending on the feature or page. What are you witnessing is end stage “enterprise disease”, brought about by a prolonged history of “Winchester-housing”, a term coined by yours truly to describe the endless addition of features without any long term architecture planning.
For the uninitiated, the Winchester house is a sprawling mansion located in San Jose, California once owned by Sarah Winchester, widow of the inventor of the Winchester rifle or so called “Gun that won the west’. As the legend goes, Sarah was compelled to endlessly continue construction on the house to avoid being haunted by vengeful spirits killed by Winchester rifles. Years of additions without any large scale planning led to windows and doors that open to nothing, stairs that lead to ceilings, and other oddities.
Much like the Winchester house, UI can fall victim to this same fate.
What causes Winchester-housing?
- A feature by feature approach.
Enterprise disease can easily be observed in legacy internal tools. Traditionally, these tools were made without designers or before UX design became a thing. They started off with a single function, people needed a solution which needed to do a specific thing. Often times the developers were in charge of the design. Being the pragmatic type, they took the simplest approach to solving this problem.
It performed well, and met the needs of the stakeholders and (hopefully) users at the time. However before long, there came requests to add additional functionality, and so the process was repeated.
Now imagine that this process goes on for years. You may end up mixing global and group level submit/save buttons, accordions with dozens of sections, side nav menus with sub menus leading to sub sub menus, and more. Eventually, this develops into full blown enterprise disease.
When the request comes in to add a new feature, there’s no time or resources to allow for radical information architecture redesign, and so the cycle continues.
Much like Sarah Winchester, we fear being haunted by the ghosts of design debt past and instead mindlessly focus on adding more features, avoiding the larger problem. The longer Winchester-housing continues, the harder it is to correct it.
2. Lack of user research
When these new feature requests come in, they are often based on what the user supposedly wants. Unfortunately this kind of research is often approached by simply asking users what they want. You’ll get feedback along these lines:
“I want to reduce the number of clicks I need to do X”
“I want to have everything in a single view”
“It would be cool if I had ____”
Taken at face value, one can certainly see how this type of feedback leads to the UI seen above.
Misconceptions
- UX Designers never engage in Winchester-housing.
False. If UXD’s are engaged too late in the product design process Winchester-housing can still occur, although it may look prettier. - Enterprise disease is limited to enterprise software.
False. While less common, enterprise disease can rear it’s head in B2C software as well.
How to avoid Winchester-housing
An ounce of prevention is worth a pound of cure.
Particularly for 0–1 products, think beyond the MVP and gather future use cases that need to be accommodated. Engage with stakeholders to gather requirements early. Run Northstar workshops and exercises to envision what the product could look like 3+ years from now.
Engage with users early and often. Particularly for enterprise this doesn’t happen nearly enough. If you don’t have access to users, find out how to get it.
Be frank with stakeholders. After using the crowded UI for so long it almost feels like home for long term users. However new users will require a 100 page manual to operate it. Benefits of fixing enterprise disease go far beyond aesthetics. Less dev hours to maintain legacy code, less time spent on key tasks, less costly human errors, less time spent on user onboarding, and more.
Conclusion
As a UXD, you were meant to do more than make things look pretty. Everyone knows this. However you were also meant to do more than churn out the next feature.
The next time you’re tempted to Winchester house to get a new feature out the door, go visit a certain mansion in San Jose and see how that worked out.
As a UXD, you were meant to do more than make things look pretty. Everyone knows this.
However you were also meant to do more than churn out the next feature. Addressing the enterprise disease elephant in the room doesn’t make you a blocker, it’s doing your job to raise the bar on user experience.
Keep fighting the good fight.
