One thing I found quite difficult when transitioning from an engineer to a designer was the idea that blue-sky brainstorming was okay. I remember during one of my first brainstorming sessions, we were trying to come up with a novel interface for dentists to interact with computers while respecting infection control. I kept shouting down each new idea as completely infeasible, until one of the interaction designers gently took me to one side and reminded me what the purpose of brainstorming is.
With that in mind, I found the following article (via The Unofficial Apple Weblog) to be quite an interesting exposure of Apple’s design process.
Every week, the teams have two meetings. One in which to brainstorm, to forget about constraints and think freely. As Lopp put it: to “go crazy”. Then they also hold a production meeting, an entirely separate but equally regular meeting which is the other’s antithesis. Here, the designers and engineers are required to nail everything down, to work out how this crazy idea might actually work. This process and organization continues throughout the development of any app, though of course the balance shifts as the app progresses. But keeping an option for creative thought even at a late stage is really smart.
This to me sounds like a fantastic approach to design. I think too often one is favoured over the other, when really, both are required for innovative yet achievable design. There were some other interesting nuggets in there too. Pixel perfect mockups is something I’ve considered using myself, except within a startup there really isn’t enough time to get this just right. With a large engineering team and plenty of dedicated graphic designers, I’m sure this is a fantastic way to get the product just right before going out.
This, Lopp admitted, causes a huge amount of work and takes an enormous amount of time. But, he added, “it removes all ambiguity.” That might add time up front, but it removes the need to correct mistakes later on.
I couldn’t help but notice there is not much mention of user experience or usability testing. It’s something I’ve always found difficult to balance myself. How much do you want to balance user experience compared to innovation? If you have really great designers working for you, usability and user perception are things they account for unconsciously and it’s virtually unnecessary to closely tie design to user testing. However not everyone is capable of (or does a good job of) cognitive walkthroughs as they design.
Through Google Reader, to BoingBoing, to