Meta-design: The intersection of art, design, and computation

Modern design products should be dynamic, adaptable systems built in code.


Editor’s note: this post originally appeared on Rune Madsen’s blog. It is reprinted here with permission.

This post is about something I see as a continuing trend in the design world: the rise of the meta-designer and algorithmic design systems.

“Meta-design is much more difficult than design; it’s easier to draw something than to explain how to draw it.” — Donald Knuth, The Metafont Book

Until recently, the term graphic designer was used to describe artists firmly rooted in the fine arts. Aspiring design students graduated with MFA degrees, and their curriculums were based on traditions taught by painting, sculpture, and architecture. Paul Rand once famously said: “It’s important to use your hands. This is what distinguishes you from a cow or a computer operator.” At best, this teaches the designer not to be dictated by their given tool. At worst, the designer is institutionalized to think of themselves as “ideators”: the direct opposite of a technical person.

This has obviously changed with the advent of computers (and the field of web design in particular), but not to the degree that one would expect. Despite recent efforts in defining digital-first design vocabularies, like Google’s Material Design, the legacy of the printed page is still omnipresent. Even the most adept companies are organized around principles inherited from desktop publishing, and, when the lines are drawn, we still have separate design and engineering departments. Products start as static layouts in the former and become dynamic implementations in the latter. Designers use tools modeled after manual processes that came way before the computer, while engineers work in purely text-based environments. I believe this approach to design will change in a fundamental way and, like Donald Knuth, I’ll call this the transition from design to meta-design. Read more…


Unleash innovation in the enterprise

Winning organizations continually experiment.

I constantly hear how enterprises are poor at innovation, bad at product development and unresponsive to business change. So it begs the question, why do so many organizations get it wrong? And what are the key factors to consider when trying to innovate in large organizations?

Typically the factors constraining innovation are conflicting business goals, competing priorities, localized performance measures and success criteria. While these have traditionally been the tools of management — to control workforce behavior and output — in highly competitive and quickly evolving business environments they also have had the adverse effects of killing creativity, responsiveness and ingenuity.

So what are the components needed to unleash innovation in enterprise?

Read more…


4 significant ways to improve your ability to innovate

Liberate teams from the annual budget cycle.


The use of the traditional annual fiscal cycle to determine resource allocation encourages a culture that thwarts our ability to experiment and innovate. It perpetuates spending on wasteful activities and ideas that are unlikely to deliver value. How can we get out of the rut that is the annual budget process and encourage experimentation and innovation within our organization?

When it comes to budgets, It is hard to let go of the long-held belief that strong, centralized control provides valuable efficiencies. However well it may have served us in an era of lower complexity and slower technical advances, it now creates barriers that prevent us from adapting quickly to emerging opportunities. In this context, the resources and efforts required to gather information, communicate, and monitor rigid centralized processes outweigh any efficiencies gained. As well, a strongly controlled centralized budget process encourages competitive, rather than collaborative, internal behavior. This is counter-productive to innovation, which requires teamwork and collaboration across the organization.

Read more…

Comment: 1

Beyond AI: artificial compassion

If what we are trying to build is artificial minds, intelligence might be the smaller, easier part.

LIght_of_ideas_Saad-Faruque_FlickrWhen we talk about artificial intelligence, we often make an unexamined assumption: that intelligence, understood as rational thought, is the same thing as mind. We use metaphors like “the brain’s operating system” or “thinking machines,” without always noticing their implicit bias.

But if what we are trying to build is artificial minds, we need only look at a map of the brain to see that in the domain we’re tackling, intelligence might be the smaller, easier part.

Maybe that’s why we started with it.

After all, the rational part of our brain is a relatively recent add-on. Setting aside unconscious processes, most of our gray matter is devoted not to thinking, but to feeling.

There was a time when we deprecated this larger part of the mind, as something we should either ignore or, if it got unruly, control.

But now we understand that, as troublesome as they may sometimes be, emotions are essential to being fully conscious. For one thing, as neurologist Antonio Damasio has demonstrated, we need them in order to make decisions. A certain kind of brain damage leaves the intellect unharmed, but removes the emotions. People with this affliction tend to analyze options endlessly, never settling on a final choice. Read more…


What is DevOps (yet again)?

Empathy, communication, and collaboration across organizational boundaries.

Cropped image "Kilobot robot swarm" by asuscreative - Own work. Licensed under CC BY-SA 4.0 via Wikimedia Commons.http://commons.wikimedia.org/wiki/File:Kilobot_robot_swarm.JPG#mediaviewer/File:Kilobot_robot_swarm.JPG

I might try to define DevOps as the movement that doesn’t want to be defined. Or as the movement that wants to evade the inevitable cargo-culting that goes with most technical movements. Or the non-movement that’s resisting becoming a movement. I’ve written enough about “what is DevOps” that I should probably be given an honorary doctorate in DevOps Studies.

Baron Schwartz (among others) thinks it’s high time to have a definition, and that only a definition will save DevOps from an identity crisis. Without a definition, it’s subject to the whims of individual interest groups, and ultimately might become a movement that’s defined by nothing more than the desire to “not be like them.” Dave Zwieback (among others) says that the lack of a definition is more of a blessing than a curse, because it “continues to be an open conversation about making our organizations better.” Both have good points. Is it possible to frame DevOps in a way that preserves the openness of the conversation, while giving it some definition? I think so.

DevOps started as an attempt to think long and hard about the realities of running a modern web site, a problem that has only gotten more difficult over the years. How do we build and maintain critical sites that are increasingly complex, have stringent requirements for performance and uptime, and support thousands or millions of users? How do we avoid the “throw it over the wall” mentality, in which an operations team gets the fallout of the development teams’ bugs? How do we involve developers in maintenance without compromising their ability to release new software?

Read more…

Comments: 2

Avoid disruption through exploration

Support experimentation and continuously evaluate to stay ahead.


Businesses have always come and gone, but these days it seems that companies can fall from market dominance to bankruptcy in the blink of an eye. Kodak, Blockbuster and HMV are just a few recent victims of the rapid market disruption that defines the current era.

Where did these once iconic companies go wrong? To my mind, they forgot to keep challenging their assumptions about what business they were actually in.

Businesses have two options when they plan for the road ahead: they can put all their eggs into one basket, and risk losing everything if that basket has a hole in the bottom, or they can make a number of small bets, accepting that some will fail while others succeed.

Taking the latter approach, and making many small bets on innovation, transforms the boardroom into a roulette table. Unlike a punter in a casino, however, businesses cannot afford to stop making bets.

Business models are transient and prone to disruption by changes in markets and the external competitive environment, advances in design and technology, and wider social and economic change. Organizations that misjudge their purpose, or cannot sense and then adapt to these changes, will perish.

The sad truth is that too many established organizations focus most of their time and resources on executing and optimizing their existing business models in order to maximize profits. They forget to experiment and explore new ideas for customer needs of tomorrow.

Read more…