Should Designers Code?

Bobtuse Honeybee Pagoda

I am an long-time programmer. I have a keen interest in simple design and providing a pleasurable aesthetic experience in most things I build.

Jon Kolko‘s post code is material: why designers must learn to code got me thinking, and predicting:

Designers don’t need to learn to code. The code will come to them.

My Programming Arc

I wrote my Hello World in FORTRAN at the University of Minnesota in the early 1980s. But I started programming in earnest as a Civil Engineering undergraduate in the mid 1980s in the days when fast was turbo.

Today I am handsomely compensated to jerk around coughed up hair balls of client-side JavaScript.

Thankfully I never had to program in machine code. One great programming leap was the advent of commonly used computer languages like FORTRAN that abstracted the complexities of machine code.

Another Great Leap

Alan Cooper in his office
at Cooper in San Francisco

Programming made a quantum leap when Visual Basic 1.0 was introduced in 1991. Visual Basic pioneered drag and drop design for crafting user interfaces.

Visual Basic derived from a form generator prototype developed by Alan Cooper and his company called Tripod.

Alan Cooper put the “visual” in Visual Basic

The visual nature of the new Visual Basic paradigm abstracted the software maker from the underlying sausage.

The Visual Basic leap for occurred after the 1991 COMDEX/Windows trade show. There have been no equivalent leaps since. We’re overdue.

The Next Great Leap – A Future for Creatives

Returning to my assertion that

Designers don’t need to learn to code. The code will come to them.

I suspect there will be a bright future for creative types. All that’s needed is another revolutionary leap in development tooling that will enable designers to do what programmers do without having to know how to code. Someone will abstract the complexity.

The explosion of rich client applications, and all of the attending JavaScript schmutz, is a programming nightmare for cats like me who have known better times.

Today’s rich client frameworks and persistence schemes have lots of hoop-jumping complications.

 Too much sausage meat! 

Take heart, I think tooling will be invented that will put the sausage back in the case.

It is laudable to know the your work environment and the materials you work with through and through. But in the case of making applications, simplification by abstraction is what frees us to be creative.

Already tools are appearing that enable applications to be built without the gratuitous and frustrating hair balls that require the services of a programmer.

So I think the code will come to the designers. Application development will be made visual, gestural, instinctual and intuitive.

Design Quest – Interaction Design Day #1

Day One of Cooper’s Interaction Design Practicum had many highlights. Some of the topics covered includes the following ideas, practices & tips:

  • Design Is – Groundwork Definitions
  • Synthesizers and Generators 
  • Pretend It’s Magic
  • Goal-Directed Design
  • Alan Cooper Q&A
  • User Interviews – Guidance & Tips


Design Is…
Cooper managing director of interaction design Doug Lemoine was our practicum leader. Doug established groundwork design definitions.

Design is the conscious and intuitive effort to impose meaningful order.
~ Victor Papanek, Design for the Real World: Human Ecology and Social Change

Good design ensures usefulness. The web-based file hosing service Dropbox is useful. The Segway Personal Transporter, not so much.

Humorous snark about the perceived need and Segway price point from fellow-attendee Matthew:

I wish I had 10 grand to make me even lazier.

In a well-executed design, people delight in simple, intuitive interactions


Synthesizers and Generators

It has been said that Cooper’s secret sauce is to work in design pairs. Cooper pairs consist of a Generator and a Synthesizer. The Generator leads concept creation,while the Synthesizer leads narrative creation.

Generator Synthesizer
  • Good at visualizing systems
  • Versed in usability & IxD principles
  • Responsible for screen sketches
  • Good at narrative, facilitation, and detail
  • Versed in communication and process
  • Responsible for documenting Research & Development

Cooper’s paired design balances generative thinking (what could the product do) and evaluative thinking (what should the product do).

Pretend It’s Magic

One pitfall is thinking about what the system can do at the expense of what the system should do. Edward de Bono‘s Lateral Thinking was presented as a problem-solving technique that uses an indirect, creative approach. Problem solving can follow a practical path, or a magical path (shown below). Often considering the ridiculous, the ludicrous, and the impossible — the magical path — leads to a great idea.

Sometimes a product vision is blurred by a natural tendency to focus on product implementation. That’s when it is time to switch off our internal editor and pretend it’s magic (e.g., what would a magical device do) or pretend the product is human (e.g., what would a human assistant do?)

Goal-Directed Design

Goal-Directed Design considers what should be built before starting to build it. Cooper has observed that goals are stable targets. The supporting example is a cross-country trip. The goals of cross-country trip, whether in 1850 or today, are the same. Cross-country travelers want get there as soon as possible, be as comfortable as possible, and travel safely.

Context, tasks, needs and tools change, but the goal remains the same. For example, air travel can be non-stop where one needs something to read for 5 hours, whereas stage coach travel had 20 stops where one needed something to read for 22 days. With air travel one wants to clear airport security, whereas with stage coach travel one had to be sure to bring a firearm.

A visualization of Cooper’s Goal-Directed Design appeared to be a DNA chain with the following elements:

  • Research – Understanding business and user’s needs.
  • Modeling – Digest the research and build consensus among stakeholders and project team. Modeling of personas and modeling scenarios.
  • Requirements Definition – Define the product experience (i.e., key user goals, functional needs, and emotional needs). Looking for the sweet spot of business goals, user needs, and technical constraints.
  • Framework Definition -A holistic view of the design using scenarios as the foundation. Focus on most appropriate concept.
  • Detailed Design – Design the product in enough detail to prove feasibility. Collaborate with engineers to ensure feasibility.
  • Implementation Support – Ensure the product is built as intended. Advocate and build empathy for the user.
Rinse and repeat!  The process is iterative

Alan Cooper Q&A 

Alan Cooper entertained questions in the afternoon. One of several things Alan said that resonated with the audience involved the conventional title of Software Architect. Cooper feels Software Architect is a misappropriated of term. The role of an interaction designer is more akin to the title Software Architect.

An architect is a person at the nexus of people, purpose, and technology — not someone working in isolation close to the metal. ~Alan Cooper

User Interviews

User interviews are one of the primary methods of acquiring intelligence for the product design. Two approaches found to work are:

  1. One-on-One Interviews – looking for an understanding of user motivations, biases, and concerns;
  2. Conduct Workshops – looking at multiple stakeholders thinking creatively and moving toward a shared vision of the product.
Some fundamental questions discussed for an effective interview:
  • What’s your role?
  • What are the benefits for the business? For you?
  • How will it make money?
  • How do you define success?

Snapshots

View of Bay Bridge from Cooper Reception
Alan Cooper signing my copies of his books

Agile Adaptations

I’ve been following the Lean-Startup movement since I wrote about it in Framing Product Development. In the Spring of 2010 I was jazzed up about Lean-Startup following a gathering at DevJam with a small group of friends where we viewed a simulcast of the Startup Lessons Learned Conference –the brain child of Eric Ries.

Yesterday I tweeted:

Several RT’d. Others commented about this distillation of ideas.


My Admission

 My Tweet was cribbed from Abby Fichtner’s (a.k.a., Hacker Chick) screencast Pushing Agile to the Next Level. The side by side comparison of Agile and Lean Startup (below) is a concise and helpful representation of an evolution of thinking in the Agile software development realm.

Of Hacker Chicks’s excellent slide and presentation, I pass on Alan Cooper‘s tweet – ostensibly directed at her vision of the evolution of the Agile movement…

Most accurate, succinct, and wise demarcation of the two disciplines.Alan Cooper

Agile 2.0

I share Hacker Chick’s vision. For me Lean-Startup has become Agile 2.0. True to the spirit of Agile, movements must adapt and adopt, or die. I recognize that Hacker Chick has shown the Agile community a bridge to the future. The challenge for any ponderous old-paradigm organization producing custom software products is

How to behave like a startup?

Lean-Startup teaches us to create the infrastructure necessary to test our business models (our products). That means getting it into the hands of the users, testing hypotheses (fail early / fail often), and pivoting toward viability — like a heat-seeking missile follows heat.


Previous Posts About Lean-Startup For those new to Lean-Startup, I’ve written several posts on my understanding the constituent principles: