Reviewing my tweet feed today, I tripped over this post.
It struck me as both something we Designers should take to heart, and something that’s a fallacy in our industry.
Should Designers question the status quo? Absolutely. If we’re doing something today because that’s how the company has always done it, there’s a strong chance we’re repeating someone else’s mistakes, assumptions, or biases.
Should Designers take the answer “because that’s what we’ve always done” to indicate that the old design was broken, flawed, filled with assumptions, or biased? Also no.
And yet, I see approaches to problems veering that way on a regular basis. Here’s an example of what can happen when you take that path.
In 2010, I was asked to do a redesign of the Balances and Holdings page of a large investment company’s website. Balances and Holdings is the page that shows you every investment you own at the company and what it’s worth — stocks, bonds, mutual funds, options, etc. etc. It’s a Big Deal, second most visited page on the site, and not something you want to screw up.
The current design was many years old and needed a visual refresh. Due to a change in the way the brokerage accounts were being held at the company, we also needed to make business-rule based changes to the account information displayed.
One of the biggest complaints that I had about the page was that it looked cluttered with a bunch of information that we didn’t need. At peer review (critique), I asked why it was done this way and no one knew, but they agreed it was cluttered.
At an early business meeting I asked the Project Managers why all the clutter was there. “That’s how it’s always been” and when I asked why, I got shrugs. (To be fair, my business contacts had about the same 7 years of tenure that I did, and while that sounds like a lot, in the world of finance at 7 years you’re just really starting to get a good grip on the rules.)
Well clearly, we decided together, this thing was put together by someone who just dumped everything they were asked for on the page with no sense of importance or structure.
We decided that in addition to the business rule changes, we were going to clean up the clutter: strip the page down to only its most necessary components, make it easier to read, and fulfill the business requirements.
We removed about 60% of the page content (mostly data points, but also dozens of help links, fly-outs, etc. etc.) and the prototype got positive reviews. We were given the go-ahead to build. And we were given an investing subject matter expert to guide us on what the SEC and other regulatory agencies required, business rules, and financial matters, for the detailed design phase.
We sat down four days out of five for at least an hour a day as a team and reviewed every use case and piece of information on the page. For six months.
What we quickly discovered was that most of the content we had removed had regulatory, legal, or security requirements behind it. The rest turned out to be guidance to keep our investors out of trouble or explain what they owned. With each day’s new information, I revised the wireframes, adding data or guidance back in.
Further, we found, even with new browser technology, etc. there wasn’t much we could do to improve the page layout or functionality of the design.
In other words, over the course of six months we found out that “it’s always been that way” didn’t mean the previous designers had been mislead, lazy, or following bad design principles. They had done a fantastic job, one that actually held up many years — and aside from the SEC-regulated business rule changes we were implementing, the best we could do to improve it was change the color scheme and improve the white space.
Was it wasted time? No. We made money and learned something.
Did we do it the hard way? Hell yes. To the point that we were almost embarrassed to show our finished design because it was so much like the old one. (At least the customers didn’t have a lot of interface changes to learn!)
But it wasn’t necessarily our fault, either. What we lacked was institutional memory. Nothing about the last design had been written down, and so we had no repository to check to see why it was important to show both the funds available to trade and the funds available to withdrawal (or even why they’d be different numbers).
It’s worth noting that all of this took place at a company where a giant IT requirements repository stored the requirements for every project going back at least five years, so finding information should have been A Thing.
Today many of us live in a world of Agile And Lean All The Things, where “write documentation” sounds old-fashioned or obtuse. One recent time I asked for the requirements that created a page I was told they’re in Jira, somewhere about three years back, in a project that spanned multiple months and hundreds of stories.
Strangely, that did not help me identify the requirements.
There are three ways that I know of to battle this lack of institutional memory and ensure that falling down the hole of “no one knows why we did it so it must be bad” is harder for my design coworkers:
Keep running capability strategy sheets at the department level for critical capabilities.
These documents help you remember why X was so important that it’s in the top 10 user goals. They help you deflect requests for changes from people who don’t know what the capability’s goals are — and want to waltz in and make changes (oh hello yes that was me). And if the whole team is creating and using them, they’re a relatively quick way to bring new hires up to speed on what you already have.
Write portfolio entries for each project and store them on the company wiki.
Yes, like, if you were going to describe how a project went for your resume and portfolio. What was the elevator pitch? What was your role and what definitely wasn’t your role? What did you accomplish? What did you learn? What would you look out for the next time?
It’s also a great way to capture decisions that might look otherwise like mistakes, such as “we used colored arrows to indicate gain or loss because a plus/minus system, used by some competitors, made users confused whether money had been added to the account or the assets had increased in value.”
You know in five years’ time someone’s going to look at your work and say “why didn’t they just use plus minus?” and by writing those decisions down (bonus points if you can link to the research study’s results) you save the next designer a lot of time questioning your decisions.
As an aside, by writing these on the company wiki we can positively critique each others’ portfolio writing skills and increase overall communications… and if we have to write portfolio entries anyway you know we’re keeping our personal portfolios up to date. Which, no matter what we think of our current jobs, is best practice for all of our sanity.
Assume the last Designer knew what they were doing
This only works if you know the last person who did the design was, in fact, a Designer. While overhauling the design system at Boomi I’ve learned that many of the “last designer”s of our current pages were Developers. And while Developers are very good at developing, they generally don’t have the free time available to become good Designers as well. (Or desire. Which is good for us because it’s job security.)
But if you know that the last time that touched something was trained in design, and especially if the capability is currently working for the customer base, also assume that they had reasons for doing what they did.
There is a level of career maturity I refer to as the “awkward adolescent years” where we’re prone to assuming the last designer was an idiot and we’re superheroes. Try to avoid doing that. Maybe no one else will notice, but you’ll know, and you’ll feel like an idiot.
If you don’t know why the last designer did something, reach out to your research team for help. Do some quick usability tests to find out what happens if you remove it. Talk to your customer support people and find out what the customers are using it for (and what their current pain points are). Talk to subject matter experts (and maybe even Legal) to see if there are regulatory, security, or legal reasons for the thing you want to remove. Then, armed with information, try taking it out.
“That’s the way it’s always been” is not validation that you should do it that way — far from it. On the other hand, it’s not validation that “the way it’s always been” is flawed, biased, or broken. It’s just a straight up admission that we don’t know why we do it, and that’s an invitation to research before you act.
Or, you know, you could spend six months discovering all the reasons the hard way.
