Designed for Humans
In my previous life, I was a civil engineer. I worked for a large power marine construction company doing structural design and field engineering. The work assignments were pretty interesting. I got to blow up a bridge, salvage a sunken vessels, and build a lot of interesting marine structures. On one of my projects, I was given the responsibility to design a set of beds for pre-stressed concrete piles. The design challenges in this project were significant. We had limited real-estate and the loads involved were higher than any previously attempted.
Beds for pre-stressed concrete have massive anchors on each end. Between them steel forms are placed and steel cables are strung. The cables are first tensioned, then the concrete is poured into the form. When the concrete hardens, you cap the cables and cut them. The result is a pile or a girder that is significantly resistant to various loads.
Following best engineering practices, I completed a structural load analysis document, a set of production blueprints with full dimensional drawings, welding, coating and assembly instructions, a bill of materials, and even a balsa scale model to help the manufacturing facility to visualize my design.
I was proud of my hard work and I felt that it was a great achievement. The day before the presentation, I went over all the calculations again and rehearsed my slides. After one last sleepless night, I arrived to the conference room to find several structural engineers, the yard superintendent, a number of field engineers from several divisions, and the chief engineer from corporate, an elderly white haired gentleman in his mid-sixties. I remember feeling confident in my ability to sell my design to them.
The entire presentation went off without a glitch. There were some stylistic comments but the overall feedback was good. After the presentation, the chief engineer stopped by, shook my hand, and said that he liked my design very much. Then with a straight face, he told me that he expected to see two additional alternative designs before we finalize our decision.
I was speechless. “I’m not sure I understand, sir” I said. “Didn’t you just say that you liked the design?” I pointed out that none of the participants had found any flaws in my proposal. “Why", I asked, “did you think we need to develop two additional designs?”
He paused for a moment, and then said, "You never know what the best idea is unless you compare several good ones side by side." I nodded politely, but I was disappointed. I felt like this was probably some form of engineering hazing. Was it truly the case that it’s impossible to achieve reasonable quality on a first try? I didn’t really understand how valuable his advice was until years later.
Completed pre-stressed concrete beds
Fast forward several years. I switched from civil engineering to software development. At the time I was working as a lead front-end designer. One of our key customers hired us to migrate a large VC++ client to a browser application. In the mid-nineties, rich browser based clients were relatively unheard of. We were stumped. Problems like session security, persistence, and lack of basic GUI controls seemed Insurmountable.
During meetings, I would regularly sketch various GUI solutions. But I often found that as soon as I came up with a solution, a new set of problems would be exposed and a redesign would be necessary. In retrospect, most of the ideas I came up with at the time were sub-par. But with each design, no matter how bad, another potential solution was discovered. Each new design I sketched out was closer to the solution than its predecessor. Even the poor designs peeled away some layers that obstructed the problem that I didn’t initially see.
After dozens of attempts, I had an epiphany and came up with one design that it was possible to implement in several ways. Sketching and contemplating the various designs helped me tremendously, but when the time came to present my solution, I made a tactical mistake. I deliberately neglected to show all of the other working ideas for fear that they would think that I was a mediocre designer; why else did I need to work so hard on so many designs just to yield one single decent one.
I realized in retrospect that there would have been any number of acceptable designs and by not presenting some other ideas I considered before arriving at the one I chose, I short changed myself. If anybody had suggested one of the other options I had discarded but not mentioned, I would have had to explain that I had already discarded that idea. But at that point , it would jeopardize my credibility because it would look as if I was only trying to brush them off.
Multiple product designs
After participating in and leading many painful design meetings, I have come to the realization that the best way to sell the top design idea is to first share some of the alternative and inferior designs.
If you are responsible for usability or user interface design, you have to develop at least several alternative options for credibility purposes. By that I don’t mean that you should become a cynic and create duds just for the sake of generating volume. The alternate ideas have to represent meaningful and functional choices.
Once you have your alternates worked out, walk through the various options during your design meeting and call out what the pros and cons are for each and what the overall solution trade-offs would be. When discussing designs, place emphasis on both the positive and negative qualities of each alternative. This will help your peers view you as an unbiased and professional presenter. Also, you may find that when you present your top candidates, your team will come up with some hybrid solutions that otherwise would have been impossible to generate if you had only presented a single one.
Nowadays, I am often tasked with working on problems that are exceptionally difficult to overcome (with respect to both technology and schedule) and the typical, off the shelf solution is just not sufficient. But there is hope. Usually after a few days of intense interterm deliberations complete with often heated exchanges of alternate designs, magic happens.
My secret sauce for breaking down the most difficult design problems consists of the following steps:
1. Get your entire team into a conference room, order plenty of pizza and write down all possible solutions on the whiteboard. Make sure that everyone offers an opinion. Don’t make any go-no-go decisions during your first meeting; rather leave the information on the board for several days (don’t forget to mark it as ‘do not delete’) and schedule a follow-up meeting. Tell everyone to document the pros an cons list for each option and provide specific use cases.
2. Get your team into a conference room a second time, order plenty of pizza and write down the pros and cons list for each choice. Boil down your choices to the top three candidates.
3. Work out the feasibility of each of the top three candidates and cast a vote for the best one. This is the time to establish consensus and a team buy-in.
Way back when the chief engineer asked me to come up with two additional alternate designs, he was in fact telling me that no matter how talented a person is, there is tremendous value in variety. He was also saying, that in order to come up with a ‘good’ design there must first be several inferior ones. If you are responsible for the design of any product futures, you will want to encourage your team to flesh out the bad designs on the whiteboard or as POC, not in your final product. Unfortunately, the only way to achieve this is by expending resources and time exploring several possible solutions, up to and including some unattractive ones.
A common development folly (see It’s Good Enough for me) is the notion that there is in fact a ‘best’ solution or one right answer to a given problem. Actually, the opposite is true. Considering time and resources, in most cases, the ‘best’ possible solution isn’t worth the effort and a ‘good’ solution would more than suffice.
If you are curious abut which design I ended up using for the prestress pile beds, it was the third one. It turns out that unexpectedly, after I reconsidered the problem again, I realized that due to the yard’s location at sea level, the water table was too high to accommodate my initial proposal. As a result, my updated design required various modifications in order to solve this problem.
Live, design and prosper.
© Copyright 2010 Yaacov Apelbaum All Rights Reserved.