37signals recently blogged about the “planning fallacy”. The basic argument is that it doesn’t matter whether you ask people for their realistic best guess or a hoped-for best case scenario. You will always get the latter.

In 37signals case, they were talking about tech projects. But the same can be said for designers.

My first day at Disney I was handed a very well prepared 3-month plan. The plan looked sound, with user research and prototype milestones. A few dents were discovered early on: It was planned I start user research week 4. In reality, I started scheduling interviews week 1. I think the team realizes the planning fallacy up front and so doesn’t necessarily track to plan, a benefit of working with great people. However, this example reinforces the idea of a design problem as inherently wicked. You have some idea where to start, but really no idea how long that will take or what will happen next.

I generally split a project into two phases: user research, technology research and design. All happen simultaneously. Putting milestones in the way of the process is akin to shoving a stick in someone’s bicycle spokes. This isn’t to say one can’t work within a timeline, just that where you go in that timeline is a yet unforeseen journey. That’s why design attracts adventurous people: it’s exciting! You have no idea where a project will take you, but it does have to end some time.

There are very few articles which seem to capture the notion of the “Apple Magic” product design as well as this one by CounterNotions - Why Apple Doesn’t Do “Concept Products”. The article examines the notion of concept products and questions it’s organizational necessity, citing Apple’s boo-design concepts approach as an example.

Showcasing Nokia’s someday-we’ll-have-flying-cars high concept wearable phone designs, the author dispels the myth that designing without technological limitations produces quality concepts years later, when ‘the technology has caught up’. Indeed, great and (more importantly) true design emerges from real world constraints, and real designers work within those constraints.

Some highlights…

Pretenders vs. Designers

There has been a good deal of off-and-on discussion within our design school about constraints, specifically how many to consider and what to consider. I urge for more understanding of technical constraints within projects while our faculty generally undertake a more concept-based approach. Philosophy aside, out of constraints come great design. I believe the MeToo! iPhone app our team designed first semester is a good example of constraints breeding creativity.

Pretenders don’t quite understand that design is born of constraints. Real-life constraints, be they tangible or cognitive: Battery-life impacts every other aspect of the iPhone design — hardware and software alike. Screen resolution affects font, icon and UI design. The thickness of a fingertip limits direct, gestural manipulation of on-screen objects. Lack of a physical keyboard and WIMP controls create an unfamiliar mental map of the device. The iPhone design is a bet that solutions to constraints like these can be seamlessly molded into a unified product that will sell. Not a concept. Not a vision. A product that sells.

Technology Constraints Don’t Disappear With Time

Why designing concepts for “10 years in the future” might not be such a good idea in practice. I personally believe this to be a good academic exercise, though a poor way to approach design in the real world.

Designers shouldn’t be encouraged to simply assume somehow constrains magically will disappear: mobile devices, for example, will somehow be powered by Herculean power sources that then make possible most of the other flights of imagination found in a typical concept phone.

Internal Design Iteration vs. Public Release

Obviously Apple creates concepts (everyone iterates) or else they wouldn’t produce fantastic designs. The difference is Apple doesn’t parade it’s concepts to the world each time they fart out a good idea.

There is some great advice for companies and for designers. For companies, why releasing your early concepts to the public might not be such a great idea. For designers, why putting that messy, first iteration sketch on your portfolio alone might not be such a great idea.

Apple is likely generating more concept products and visions than any other technology company for internal use. When Apple wanted to get into retail stores, for example, Jobs had Ron Johson build a fully-functioning, real-size prototype and tore it down at the last minute to rebuild a new one. Why didn’t Apple release the “concept store” to the then-deeply-skeptical press in order to “demonstrate visionary leadership”? In a similar situation Microsoft likely would have.

Product design, above all, is a bet. Apple understands this better than any other company. In iPhone: The bet Steve Jobs didn’t decline, I explained just what a huge bet the iPhone project was to Apple in 2005. It was a bet-the-company kind of bet. One that Nokia, which has sold hundreds of millions of phones over many years, never took. Neither did Microsoft. They would just as well release annual concept products to the public in order not to go through the pain of taking a bet.

Bill Buxton recently wrote a piece for Business Week entitled, “On Engineering and Design: An Open Letter“. In the article Buxton points at a broader need for engineers to respect the skill required for a designer to properly address design decisions.

About halfway down, however, he lays basic groundwork non-designers might follow to get into design thinking. These are simple yet effective starting points for anyone interested in design, really:

Design awareness for every worker

None of this is to suggest that it is not worth your time to build up your knowledge of design. To help guide you in your approach, it might be useful to think of design in terms of four layers, each demanding a progressively larger investment.

Design awareness can and ideally should be something that every employee of a company makes their best effort to acquire. I would say exactly the same thing about technology awareness. In the corporate culture I dream about, there would be a balance between the two—along with a healthy respect for best business practices—in every employee.

Design literacy is also something that can be acquired with a bit more effort by any employee, regardless of background. If your company has employees who suffer from “Apple (AAPL) envy” in terms of the nature of the products that they produce, building such literacy is a very real and useful step in helping combat that particular affliction. Designers need technological literacy, too, and both need an equal dose of business acumen. Without this, none of us has any right to complain about not being understood by those in other disciplines. We all need to be able to handle multiple directions.

Design thinking is something that takes even more of an investment, requiring a level of competence that—with dedication and practice—can be acquired by anyone, to a reasonable degree. Cognitive science makes it clear that the strategies designers use in approaching problems or questions are different (not “better”) than those employed by those trained in engineering disciplines. Both strategies are complementary. Given the complexity of the problems that confront us, it seems to me that expanding our collective arsenal of techniques is something we could all benefit from.

Design practice, however, is not something available to everyone. This is a full-time job for highly trained professionals. It requires people who have invested just as much to acquire their set of skills as the computer scientists have put in for theirs. Yes, there are exceptions. There always are on both sides of the table. But it is risky, if not foolhardy, to generalize from the exception.

Bill Buxton hides behind a rather frightening clock

The question seems to be popping up more and more on the IxDA boards as employers begin to expect more of their designers, and designers begin tooling up on technologies to better facilitate their work. Flash has become the de facto standard for professional, hi fidelity interaction design prototypes. One rarely sees a job posting for an interaction/experience designer without the requirement for some competency in Flash or Flex within it. It is no wonder that this question has been given more weight. However, I think the real question is, what exactly is it that you want to do with Flash?

For many, Flash is seen as the jack of all trades: designers can create neat-o animations in Flash, while the developer across the hall can write a fully functioning Rich Internet App using the same development environment. Mock-ups and prototypes are seemingly easy to create in Flash, which makes it understandable why interaction designers seem attracted to it.

This same jack-of-all-trades approach is also Flash’s greatest limitation. In the 5+ years I have been using Flash I am still unclear for whom it is designed. I have witnessed folks from both a design and development competencies spew enough bile about the application to fill a moat, yet, it is often their bread and butter. It is important to remember that Flash is just like any other technology with it’s strengths and weaknesses, tricks and traps.

From Dane Petersen’s Tumblr

Flash was originally designed by the now defunct Macromedia as a multimedia tool with a programmable twist (ActionScript). As demand grew from the development community, the focus on future releases quickly became the actionscript side, which at the time of ActionScript 1.0 was severely broken. As ActionScript 2.0 rolled around these update iterations continued on the developer-side as companies began using Flash for their Rich Internet App solutions. This tradition seems to have continued with the Adobe acquisition through CS4. Flex was released to much fanfair to “answer the developer conundrum”, as it leverages a scripting language for the interface and components (MXML) where Flash does not. It is also a much more more streamlined environment for creating Rich Internet Apps, albiet with much less control on the designer-side.

I’m getting off point here. Should “you” learn Flash? It depends. Why are you learning Flash? If this is to fulfill a requirement for a job, that is probably a very poor reason to learn Flash. Flash, as you can tell by all my rambling, is a messy beast filled with frustrating surprises at every turn. Learning Flash for the sake of learning Flash will simply not work. The learning of Flash must be approached in a project-by-project basis. With much practice, the Flash designer/developer can quickly create fluid high-fidelity prototypes with usable interface components, but when I say “much practice” I do mean more than one or two projects. And sadly, there is no book or books that will teach you everything you need to know as a HCI-practitioner-using-Flash. It is very much something you must work with ably and often to fully appreciate what it’s strengths and limiatations are.

A much better question to “Should I Learn Flash” is “Should I Use Flash”? There are many tools out there for simple prototyping. Mock-ups and animations can also be completed in Adobe Fireworks with similar UI functionality to Flash. I’ve even heard of people using the advanced PDF features for presenting screens to users. That being said, Flash can be a powerful tool for creating versatile hi-fi prototypes in a short period of time. It is a great tool to have at your disposal, and worth looking into if not experimentally on side projects. At the end of the day, Flash is just one of many tools in the designers aresonal.