One of the speakers at Ignite Seattle 8 was Wendy Chisholm, who works for the UW and is co-author of Universal Design for Web Applications. Her talk was about incorporating accessibility into design. I won't go over what she said here -- it'll be up on YouTube soon enough and you can watch it for yourself (I recommend it).
But I want to write about the following equation that she included in her presentation:
Her point was that many things that are done for the purpose of inclusion (to make things more accessible) result in innovations from which far more people benefit. It's a good argument, the same one made for the space program and I agree with it completely. I would go further, though:
This statement is fundamental to the way I design things and the way I approach many things in life.
One of my favorite personal examples is the competition to design a memorial for the World Trade Center. I entered, along with more than 5,000 other people. There were a lot of requirements given for the memorial, including such things as boundaries, elevation, and required ramps and staircases. I looked at each of the requirements and asked myself how the requirement was an opportunity. How could I design a memorial such that not only was the requirement met, but it was essential? What design would make it so that people visiting the memorial could not even imagine it being any other way? Maybe they'd even think the requirement was my idea rather than something forced on me. This is one of the hallmarks of great design -- when the design is so obviously correct that you can't imagine how it can be otherwise.
My design met every single requirement and it did so organically, embracing the requirements, not fighting them. I was particularly proud of the way the ramps (that were complained about by entrants) were the linchpin of the experience my design would have provided. In contrast, every finalist ignored many (sometimes most) of the requirements. And in the other entries that I looked through -- and there were many great entries beyond the finalists -- the ramps requirement was the most ignored. It turned out that the requirements weren't really required, something I might have known if I had any background in architecture. To state the obvious, no, I didn't win the competition, not even close. As was clear from the finalists, they were looking for something monumental and my entry wasn't monumental -- I designed an experience, not a monument.
It shouldn't have been too much of a surprise that the constraints were fluid. This happens all the time in the world of computers. But that shouldn't stop us from embracing the constraints as we know them. By turning constraints into opportunities, we get innovation.