Program Design

Whereas the early part of my career focused on the design of software products—everything from how a user accomplishes a task through the features and functionality of your product, to how you incentivize and constrain certain behaviors as users engage with others—most of my work in the past decade has really been about designing programs, which is roughly defined as how people navigate physical spaces and fixed time frames to achieve some desired end result.

For example, as a teacher at SVA IxD, my job was to design a 16 week experience, marked by weekly 3-hour seminars by which a set of students would learn something useful.  At USV and Orbital, I ran a variety of in-person events (ranging from hour-long to multi-week durations) where people would gain knowledge and support from their peers.  I've designed and run similar events for the Trilogy alumni—instead as multi-programs—for former colleagues to share what they've learned.  And, with the Orbital Members, I've run rituals that enabled similar interactions with a disparate group of people over a multi-year period of time.

Just as designing software products employs the use of design patterns, all of these programs can be distilled down into primitives which are often recombined into new rituals.  Similar to designing how software products should work, figuring out the design of programs requires a fair amount of experimentation and iteration.  Through that, you start to build up your own pattern library along with an intuition regarding what will and won't work.

The biggest difference between designing software products and programs is that when you're designing in-person programs, the feedback is fast and immediate.  You know instantly whether something is or isn't working.  And when it's not, you need to be prepared with a backup plan you can immediately deploy.  In the world of software, you don't need to react quickly unless you have a critical bug where people are being harmed.  Your personal reputation isn't at stake because you're so many degrees removed from the end user, whereas with in-person programs you risk losing the trust of your audience if you fail to act.

In many ways, I've become a much better designer—broadly—because of the work I've done in designing programs.  It's forced me to identify and understand my own tendencies and gaps in my process and judgement and to deal with them.  When you're designing software, you don't get the richness of information that you do in-person, and it's easy to neglect your own flaws and fall into trap of blaming users or ignoring problems that take up too much time and energy to solve.  You simply can't ignore problems with in-person events.  You have to act.  And such, I'd argue that designing programs is a faster way to grow and develop as a designer.

For a long time, I saw Program Design as a departure from my previous career.  That is, in many ways it felt like a liability because it was taking me further and further away from being "current" as a software product designer.  What I'm starting to see is that it's not an either/or, and in fact, given that we're in the Deployment Phase, these things actually go together.

It's not simply sufficient to solely understand how to be proficient at designing software, largely because many of the critical affordances aren't going to be part of the UI or the code.

For example, let's take either a Webinar or a Livestream as an example since they're top-of-mind in the pandemic world we live in.  

The quality of the participant experience in either of these scenarios is in-part a function of the design of the software and what capabilities it provides both the audience and the presenter/streamer.  But the software itself doesn't actually ensure you'll create a good Webinar or Livestream.  The host/performer needs to know how to run an efficient or compelling event by making good design decisions:

• whether to pause and take breaks,
• whether you are solo or have guests,
• whether you should run for 30 minutes or 3 hours,
• whether you should incorporate the audience into the program or make it strickly performative,
• whether you should see the faces of people or not.
• and much more

You could have designed amazing software that gets used poorly, which will be a disaster.  Just focusing on making great software is not just insufficient, it's a strategic misstep, as you leave the door open to a competitor who clones your functionality but ensures that software is used well.

Consider platforms like Etsy and Kickstarter, where there's a tremendous amount of work in building the software, but a similarly tremendous effort in thinking through how they cultivate communities of support for their sellers and creators.  Such support is less about how to use their specific technology, but more about what it'll take to be successful broadly.

An extreme is Superhuman, infamous for requiring their customers to go through a live on-boarding experience before they're allowed to use the product.  It's a great example of knowing when to rely on product design and when to rely on program design.  Ultimately, it likely postively impacts their churn, loyalty, and other success metrics.

A more interesting example is Basecamp, which I've been testing out over the past month.  Basecamp is a pure software product—there's no accompanying in-person experience—however, it's an incredibly opinionated—in a good way—and thoughtful software product that considers how they want the whole team to behave, not just the indivdiual who is using it.  In effect, they're doing Program Design through carefully considered software design.  (Specifically, look at how everything is designed to be asynchronous by default.)

All of these companies approach designing the end-to-end user experience in a different way—sometimes with separate Product Design and Program Design efforts, or in rare cases like Basecamp, through a blend—all for good reason.  They're different teams of people working in different industries in different contexts.

But as a checklist when you're creating something new, here are a few good questions to consider:

• Does the ambition of your scope match your available resources?  Are you pursuing a broad strategy which makes ensuring a great last-mile user experience untenable?  Are you hoping to get lucky?
• Is the team structured in a manner that inadvertently inhibits the execution of a good end-to-end user experience? Are there organizational gaps, walls or power imbalances that are out of sync?
• Given the plethora of off-the-shelf software tools out there, does the business you're pursuing even need custom-built software at all, much less the cost overhead of operating a software company? Or, do you just need some great Program Designers?