Listening to users is the start not the end – Design Monday

Archive for the ‘Design’ Category

Listening to users is the start not the end – Design Monday

Posted by

Good design starts with listening to the user. This is the starting point for good security, too. But if we look at the LEGO playsets my kids grew up with, we can see how simply listening to users only gets us so far. In fact, given some of the outrage LEGO faced, it’s clear listening can even get us into trouble.

After nearly going bankrupt, LEGO turned to design thinking to reimagine its toy line. LEGO partnered with PARK to develop a design process. The process begins with exploring, begins with field research, beings with actually talking with the kids.

Imagine LEGO researchers sitting with ten-year old boys. Imagine it is around 2008 or 2010. Imagine the researchers showing the boys posters of minifigures. Minifig super-heroes fighting aliens. Minifig samurai. Minifig ninjas. Minifig action-heroes fighting mechwarriors. The question was, which stories were most exciting to the kids? What sparked play?

Ninjago was the result. A set of ninja minifigs which battle with skeletons on a spinning or flying disks. This would spawn over 250 playsets and a television series that ran for ten years, and is still being produced as of this writing. 

Fresh off the smash hit of Ninjago, flush with excitement of finding great ideas by actually talking with kids, LEGO replicated the design process with LEGO Friends. This time imagine LEGO researchers sitting with ten-year old girls. Same process. Different results. Girls expressed different play and different preferences. One insight I read, for example, was the minifigs needed fashionable shoes.

When LEGO Friends hit in 2012, it faced almost immediate public backlash. Many felt it reinforced stereotypes with pink bricks and scenes like shopping and childcare. Others felt it reinforced gender segregation, as the minifigs (redesigned for shoes) in the LEGO Friends set weren’t compatible with other minifigs and standard sets.

Seven-year old Charlotte Benjamin wrote a letter that captured the frustration. “Today I went to a store and saw LEGOS in two sections, the pink and the blue. All the girls did was sit at home, go to the beach and shop, and they had no jobs but the boys went on adventures, worked, saved people, and had jobs, even swam with sharks.”

LEGO had learned how to listen carefully to the kids. The problem was they hadn’t listened to the opinions of the parents, educators, and other stakeholders. Both young boys and young girls gave great feedback, feedback which resulted in great toys. Like Ninjago, LEGO Friends currently has over 250 sets, with television and other media. But the tight lens on the end user during exploration meant LEGO didn’t look beyond the playset. By not considering the wider context in which play happens, they fumbled the release.

This is an easy mistake for cyber security architects and designers to make.

We embrace the idea of empathy as the heartbeat of the design process. Flush with early successes, we listen closely and carefully to one segment of our workforce. Let’s suppose it is the finance team. Let’s further suppose we collaborate to reduce some security controls here, tighten others there, reducing friction for the team. Success! Except, six months later when the auditors come in, we realize our changes resulted in audit evidence no longer being collected, leading to a failed audit.

We addressed the needs of our target audience without considering the wider system in which they played. Hypothetically speaking, of course. Right. Back to LEGO.

“We listen very carefully to the opinions and input that people share,” LEGO wrote in the press release in response to the LEGO Friends uproar. “We will continue to do so as we develop the LEGO brand to deliver the best experiences with the strongest appeal, and we will review our communications to ensure that we represent LEGO play for all children.” With sets like the Research Institute (women chemist, paleontologist, astronomer) and with the LEGO movies, we can see LEGO’s design thinking process improves by widening the lens for field research.

Listening to users is the start, not the end.

When designing cyber security capabilities, listen carefully and consider all of the stakeholders. When our work helps people swim with sharks, we better remember the shark.

Afterwards

I learned of these stories from David Robertson. He wrote the book on LEGO’s recovery, Brick by Brick: How LEGO Rewrote the Rules of Innovation and Conquered the Global Toy Industry. Robertson also covered the LEGO story in a wider context in his recent book, The Power of Little Ideas: A Low-Risk, High-Reward Approach to Innovation.

LEGO Friends, photography courtesy Huw Millington

This article is part of a series on designing cyber security capabilities. To see other articles in the series, including a full list of design principles, click here.

Define what we do by what we don’t – Design Monday

Posted by

“The essence of strategy is choosing what not to do.” — Michael Porter

Enzo Mari often repeated “form is everything.” The Italian designer produced thousands of works, staying active until his death in 2020 from Covid-19. Mari’s work has a clarity and cohesiveness which cyber security often lacks.

“Enzo Mari is a total work of art,” said Hans Ulrich Obrist. “Everything went together with him.” Hans Ulrich Obrist, director of the Serpentine Gallery in London, was developing a retrospective on Enzo Mari before the pandemic hit. Mari was the master of individual form, and a master of collective form, unifying them a cohesive whole. One could spend a lifetime as CISO and still not build a security program as unified as Mari’s 16 animali puzzle.

“There is only one right form, not several,” Enzo Mari insisted. To get to the essence of the form, the designer must strip away everything. Everything. The designer must explicitly decide what the design is not, in order to make the design what it is. Take the Timor calendar. Compare it to your calendar. There’s no writing in the margins. There’s no tabs or colors, no holidays or birthdays, no reminders, and certainly no notifications. There is no excess. Timor is a calendar. Nothing else.

It is bold to say no. It takes courage to say what we will not do.

Suppose we are designing a software security program. For the purposes of this example, suppose we are lining it up to OWASP’s Software Assurance Maturity Model. SAMM has fifteen practices and forty-five objectives. Most security professionals would focus on getting a handful right. Most would speak loudly about what’s being done, and mumble about the objectives that are being ignored. Instead, we should channel Enzo Mari. Banging a fist on the table, we should declare which practices we will not do. By saying no, we create space and commitment. Only then can we build the committed practices, working towards something that fits like one of Mari’s puzzles.

Good security is clear about what it doesn’t do.

Obrist’s exhibition is currently on display at the Triennale Milano (Enzo Mari curated by Hans Ulrich Obrist with Francesca Giacomelli). It may be the last public showing. If Enzo Mari’s work can be defined by his declaration of what his work isn’t, then Mari’s last act is a defining one. Mari bequeathed his collection to the city under the condition that none of it be displayed for 40-years.

Simplicity in form, Timor Desktop Calendar, designed by Enzo Mari

This article is part of a series on designing cyber security capabilities. To see other articles in the series, including a full list of design principles, click here.

Tell a story with the project name – Design Monday

Posted by

The city is a book of poetry writ large across buildings. Santiago, Chile.

During the mid-1990s, Santiago went through building boom. The game was simple. A development investment project would be conceived and pitched. If the enough investors were interested, the project was funded, and the building was built. An apartment building here, an office building there. And key to the success of getting funding? The name.

Rodrigo Rojas, a poet and professor, played a key role in naming these buildings. “Rodrigo was a kind of interpreter of dreams — he tapped into the psyche of what the people of Santiago wanted to become, and tried to give that a name.”

Every project needs a name. Unfunded real estate projects and security projects, doubly so. Here are a few things I’ve learned from naming projects.

Be playful and fun. In my consulting days, to protect confidentiality, we wrote a name generator. We dedicated a portion of the project kick-off to laughing over possibilities. With names like Iron Taco and Gubbins Dance, you can’t go wrong. Security needs a spirit of play.

Share the vision. “One system, one team” was what I called my DevOps and IT modernization project. The clarity of the name simplified sharing the vision and making downstream decisions.

Address concerns. When I received feedback that my approach to managing several consulting practices was too complex, I came up with a three year roadmap in three words. Simplify, optimize, expand. One word per year. We executed on this from 2017-2019, with quarterly goals reinforcing the overall journey.

We need to find the spirit of a poet when naming security projects and initiatives. Tell a story with the name. Make it fun, while communicating the vision and addressing any concerns. We can use the name to drive action.

Photography courtesy of Horst Engelmann, Pixabay

This article is part of a series on designing cyber security capabilities. To see other articles in the series, including a full list of design principles, click here.

Find your own way without brainstorming or crowdsourcing – Design Monday

Posted by

Imagine you are getting onto a train. Drive. Park. Traverse the crowds. Find the train. Sounds simple and, in many places, it is simple. But Millbrae Station is a difficult space to navigate. In fact, locals would tell you to find somebody to guide you. At least, for the first couple times, because it is easy to get lost. Bring a friend. Recently, San Francisco’s Bay Area Rapid Transit (BART) brought in studio1500 to design a better way.

The challenge was bigger than the space. There is an information system which guides people through the BART public transportation system. Broadly, this known as wayfinding. Specifically, in San Francisco, this was a set of design choices made by different firms at different times. BART’s internal team would be implementing the wayfinding system at Millbrae Station. The colors, typeface, paint choices, all these and more had to come together in a design that coordinated and communicated with multiple parties. One final consideration was how the design would be kept up. Public transportation departments routinely touch-up and refresh signage over the lifetime of a project. 

Wayfinding is an analogy for thinking about how people navigate the various screens, sites, security systems, prompts, and challenges. Our workforce navigates wayfinding systems done by others (say, WorkDay and SalesForce) at the same time they’re working through what we control (say, VPN and SSO). An example of a wayfinding design, across multiple environments, with strong need for maintainability, such an example is fertile ground for cyber security lessons.

Returning to Millbrae Station, you might expect the story to begin with a brainstorming session with the studio1500 partners Julio Martinez and Erik Schmitt. You’d be wrong. It’s cool. I was wrong, too. In fact, Martinez himself wrote: “I assumed life in a design team would be full of brainstorming sessions — mythical, lively, fast-paced meetings with brilliant ideas bouncing off multiple heads until they were captured in someone’s notebook as shiny kernels of greatness. There would be roars of celebration and laughter, hugs and high-fives, uproarious chants.”

Several years ago, I took an improv course. During my time spent learning how to Zip-Zap-Zop, I realized I wasn’t fast at coming up with ideas. Someone would shout a premise, I would freeze, and others would jump in. This wasn’t surprising. After all, I took the course because I felt slow. I decided to take each improv class twice. Double down. Work through it. And here is where I ran into a surprise. Across different classes, with entirely different teammates, with different composition of ages and backgrounds, the exercises were remarkably the same. I froze. Others jumped in. But no matter who it was, in both classes, people made essentially the same joke.  

Free association isn’t all that free. It’s bound by shared experiences and cultural expectations. 

David Palermo and James Jenkins studied free association with words in the 1960s. Simon De Deyne is studying this today. (Check out https://smallworldofwords.org to participate.) If you give someone a word, you can be reasonably certain what word they’ll think of next. Likewise, if you give someone a premise, you can be reasonably certain what they’ll improvise. Our first instincts feel creative but actually repeat what most anyone else would do. 

Brainstorming tries and fails to avoid the work of preparation and contemplation.

Mihaly Csikszentmihalyi, the psychologist who popularized the concept of flow, once said there are five stages in the creative process. This was after interviewing a hundred designers and artists, including Don Norman, so we can assume Csikszentmihalyi was on solid ground. The five steps are: preparation, incubation, insight, evaluation, and elaboration. Incubation can take days, weeks, or months. Scheduling a brainstorming session for a Tuesday at 4 o’clock, showing up, and jumping to insights feels tantalizingly innovative. But it ignores decades of research into how creative work gets done unconsciously.

Okay, but what does improv have to do with wayfinding, you ask?

“This dance between the conscious and the unconscious is important,” Martinez explained. Instead of brainstorming, they read the brief. They walked the site. Martinez made time for his observations and intuitions to gel. When studio1500 presented to BART, they came with a number of thoughtful options for the Millbrae Station. They came with ideas to discuss and build upon.

“Our approach is antithetical to the classical Paul Rand model of design. You have one idea. You show up. It is a God-given idea and it is done. Take it or leave it.” Martinez said, contrasting studio1500‘s approach. “We like to play. We like to think as we’re designing. It’s collaboration. It’s iteration. It’s actually how you figure the ideas out.”

The Millbrae Station wayfinding would go through a few iterations. The design firms working within and without gradually got onto the same page. Martinez worked to make sure the vision was translated and executed properly. This meant simplifying the design a bit, choosing colors that were more maintainable. It also meant some rework to get the typeface correct. Each change required thought, but none required a storm of ideas and flurry of sticky notes.  

Brainstorming is theater. As security theater makes us feel secure without actually increasing security, brainstorming makes us feel insightful without producing insights. 

Don’t feel pressured  to crowdsource or brainstorm ideas. Prepare by setting a vision, thinking through how to protect the organization and define the security capability. Give it time to seep into your subconscious. You’ll be ready the day comes for creatively defining architecture and controls.

When designing cyber security capabilities, find your own way.

Afterwards

In past articles in this series, I’ve covered four of my preferred ways for exploring problems and discovering new possible solutions. These are:

Julio Martinez recommends James L. Adams’ book, Conceptual Blockbusting: A Guide to Better Ideas. The book is now on my end table.

Bay Area Rapid Transit (BART) Map, Courtesy Wikipedia

This article is part of a series on designing cyber security capabilities. To see other articles in the series, including a full list of design principles, click here.

Cyber Security Design Studies, Papers, Books, and Resources

Posted by

The cyber security design principles emphasize psychology over technology. Here is a collection of scientific studies, research papers, design books, and related resources.

This is part of a series on designing cyber security capabilities. To see other articles in the series, including a full list of design principles, click here.

Paths They Take

Number of steps; Familiarity of each step; Friction at each step.

Introduction to Customer Journey Mapping (ebook)

Flow Design Processes – Focusing on the Users’ Needs

Scientific Articles

Shosuke Suzuki, Victoria M. Lawlor, Jessica A. Cooper, Amanda R. Arulpragasam, Michael T. Treadway. Distinct regions of the striatum underlying effort, movement initiation and effort discounting. Nature Human Behaviour, 2020; DOI: 10.1038/s41562-020-00972-y

G. Suri, G. Sheppes, C. Schwartz, J. J. Gross. Patient Inertia and the Status Quo Bias: When an Inferior Option Is Preferred. Psychological Science, 2013; DOI: 10.1177/0956797613479976

ulia Watzek, Sarah F. Brosnan. Capuchin and rhesus monkeys show sunk cost effects in a psychomotor task. Scientific Reports, 2020; 10 (1) DOI: 10.1038/s41598-020-77301-w

Choices They Make

Number of choices; Predictability of the choice; Cognitive load of each choice.

Nudge to Health: Harnessing Decision Research to Promote Health Behavior

Sludge: “activities that are essentially nudging for evil”

Intentional and Unintentional Sludge

Books

Choosing Not to Choose, by Cass Sunstein

How to Decide: Simple Tools for Making Better Choices, by Annie Duke

Being Wrong: Adventures in the Margin of Error, by Kathryn Schulz

Scientific Articles

Sunstein, C. (2020). Sludge AuditsBehavioural Public Policy, 1-20. doi:10.1017/bpp.2019.32

Soman, Dilip and Cowen, Daniel and Kannan, Niketana and Feng, Bing, Seeing Sludge: Towards a Dashboard to Help Organizations Recognize Impedance to End-User Decisions and Action (September 27, 2019). Research Report Series Behaviourally Informed Organizations Partnership; Behavioural Economics in Action at Rotman, September 2019

Chadd, I., Filiz-Ozbay, E. & Ozbay, E.Y. The relevance of irrelevant informationExp Econ (2020). // Unavailable options and irrelevant information often cause people to make bad choices. The likelihood of poor decisions is even greater when people are presented with both.

Behavior

The behavior we want people to perform.

Scientific Articles

Hall, Jonathan D. and Madsen, Joshua, Can Behavioral Interventions Be Too Salient? Evidence From Traffic Safety Messages (September 16, 2020).

Barriers

Barriers preventing people from completing the behavior.

Scientific Articles

Benefits

Benefits of completing the behavior.

Scientific Articles

Training (Ignorance)

Scientific Articles

Irrationality

40 Clever and Creative Bus Stop Advertisements

Scientific Articles

Vadiveloo, M. K., Dixon, L. B., & Elbel, B. (2011). Consumer purchasing patterns in response to calorie labeling legislation in New York City. The International Journal of Behavioral Nutrition and Physical Activity, 8(1), 51-51.

Fernandes, D., Lynch, J. G., & Netemeyer, R. G. (2014). Financial literacy, financial education, and downstream financial behaviors. Management Science, 60(8), 1861-1883.

Investments

More people, better technology.

Scientific Articles

Incentives

Books

Drive: The Surprising Truth About What Motivates Us, by Daniel H. Pink

Scientific Articles

Gneezy, U., & Rustichini, A. (2000). A Fine is a Price. The Journal of Legal Studies, 29(1), 1–17. doi: 10.1086/468061

Rey-Biel, Pedro & Gneezy, Uri & Meier, Stephan. (2011). When and Why Incentives (Don’t) Work to Modify Behavior. Journal of Economic Perspectives. 25. 191-210. 10.2307/41337236.

Behavior Economics

From “Economic Man” to Behavioral Economics

Related Books

  • The design of everyday things, by Don Norman
  • Designing for the digital age: How to create human-centered products and services, by Kim Goodwin
  • Design research: Methods and perspectives, by Brenda Laurel
  • User experience revolution, by Paul Boag

Presentations

Does security have a design problem? Designing Security for Systems that are Bigger on the Inside.

How does design apply to securing application development and DevOps? Securing without Slowing.

How does design apply to BYOD and Cloud apps? Security Design Strategies for the Age of BYO.

How does design apply to blue teaming? Design Thinking for Blue Teams.

Minimum Viable Security – Design Monday

Posted by

My focus on IT security began in 1997 with a malware outbreak. To get a sense of how much has changed, I checked out the (ISC)² website as it existed back then. Whoa. It’s ugly. The website and the views on cyber security have drastically improved since the nineties.

These days I regularly get asked, “where do we begin?” Privileged Access Management is supposed to look like this. Zero Trust Architecture is supposed to look like that. We only have a these two things, a paperclip, some duct tape, an overworked staff, and an intern. Where do we even start?

Borrowing from the product design world, take a Minimum Viable Product (MVP) strategy. Take a limited number of security controls. Take a limited scope of people and systems. Design a security capability, implement it, and get feedback on what works and where improvements are needed. Then, rinse and repeat with refined controls and in a new area of the organization.

A concern is that this process may lead to a patchwork of controls assembled from a tangle of point solutions. Valid concern. We’ve all seen such environments. A few of us have been lucky enough to build such mistakes, and learn from them. The way to avoid this is to use a consistent set of architecture patterns and project templates. Each sprint begins with these patterns and plans. Each one ends with updating the architecture and PMO libraries. It’ll be ugly, but with a controlled process, it’ll improve rapidly.

Criminals don’t care that we got the capability perfect. Adversaries aren’t impressed with the beauty of our control framework. So toss out the textbook.

Start where you are. Dare to be ugly. Iterate and improve.

The (ISC)² CISSP webpage from 1997, courtesy of The Internet Archive.

This article is part of a series on designing cyber security capabilities. To see other articles in the series, including a full list of design principles, click here.

Hold a value, make a decision, change a life – Design Monday

Posted by

“Develop people, develop security.” That was our tagline for the SimWitty team. The order reflected our values and simplified decisions. What to prioritize, developing a skill in a teammate or getting a release out the door? When develop people comes first, the answer is clear.

“Make a loan, change a life.” That’s Kiva’s tagline. Kiva has significantly more impact on broader social issues than SimWitty ever had, and it’s barely a comparison. There is one thing both have in common: values reflected in slogans resulting in decisions.

Kiva had a challenge. While its goal was to change lives through loans to small businesses, most businesses weren’t completing the application. The conversion rate was less than 1 in 5. Kiva looked to make design changes to simplify the application process. Many suggestions were made. One suggestion was particularly counter-intuitive to the point of being controversial: give small businesses a deadline.

“The founder was appalled. By giving customers a deadline, the company would have to deny service to people who missed that deadline. Denying service, the founder argued, was not a part of their company values,” wrote Kristen Berman, founder of Common Cents and Irrational Labs, who championed the design work for Kiva.

Security leaders must bring a degree of clarity to their team. Our values must be clear. Our criteria must be clear. And how we’ll try things and evaluate decisions must be clear. For Kiva, that meant changing lives through access to capital, with the number of people who complete loan applications as one measure. What does it mean for a security team?

Berman’s team went to work and experimented with deadlines. The number of completed applications went up. They experimented with incentives for early completion. Application rates went up further. More small businesses than ever were completing applications, resulting in changing more lives than ever. The decision to move ahead with the approach was clear.

This series has covered security programs reflecting strongly held corporate values. It’s equally important that a security leader have strong personal values, and that these values are reflected within the team. As Kiva’s example illustrates, there are times when options, on the surface, run contrary to our values. The path forward is to have a clear definition of success within those values.

Clarity enables experimentation and innovation while remaining true to what we believe in. Security leaders design capabilities and lead teams that reflect their personal values.

A case study in behavior design to reflect values. Read about the Kiva app redesign here.

This article is part of a series on designing cyber security capabilities. To see other articles in the series, including a full list of design principles, click here.

Anti-patterns and Patterns for Directing Security Projects – Design Monday

Posted by

An implementation is like a movie, directed by leadership and produced by project management. Successful security implementation projects start strong, start with style, start like movies. As projects are running, what else can cinema teach us?

I began this series of cyber security design principles with an insight: to see things differently, look at different things. Spend a week with an artist, designer, or director. Find a security lesson. Share what I find. Sometimes my process is easy, sometimes difficult. Yet no one has challenged me more than Federico Fellini.

Federico Fellini. Distinctive, acclaimed, the Italian filmmaker was legendary in the twentieth century. He directed thirty-one films, “was nominated for twelve Academy Awards, and won four in the category of Best Foreign Language Film, the most for any director in the history of the Academy.” You’ve seen a movie scene inspired by (or directly copied from) a Fellini film. It’s guaranteed. Let’s take one example: Fellini’s Casanova. The film follows the titular Casanova on an adventure across Europe, while highlighting what makes Fellini a legendary director and a example for cyber security.  

Anti-patterns in project management from Fellini’s Casanova:

  • Micro-manage your people. “Puppets are happy to be puppets if the puppeteer is good,” Fellini said of his relationship with his actors. Donald Sutherland, who played Casanova, described it as being the worst experience of his filmmaking career. Every action micro-managed and scripted, until nothing of the talented actor remained.
  • Force your people to fit your stereotype of talent. Sutherland is unrecognizable as Casanova. Fellini has him wearing a false chin and nose. He raised Sutherland’s hairline, which then necessitated false eyebrows to even the look out.
  • Over-engineer details that don’t affect the final result. Fellini, unsatisfied with the color and waves from the water, had a plastic simulated lake created for Sutherland to row across. Almost a decade later, furious the color blue wasn’t the right color blue, Fellini would delay production while an entire faux ocean shore was created with plastic sheets for And the Ship Sails On.    

James P. Carse popularized the idea of finite and infinite games. Most games we are familiar with are finite: you play to win, you play to maximize your results at the expense of the other players. Infinite games ongoing: you play to continue others to play. Federico Fellini films were finite games. Sutherland never worked with Fellini again. By contrast, the Golden Age of cinema was an infinite game. (Well, infinite, until it stopped in the 1950s.) Major film studios had in-house production crews and contracted actors. While the roles varied and films came and went, the directors were incentivized to keep the best people playing with them.   

Cyber security in an organization is like the Golden Age of cinema. The leader’s role is encouraging people to want to play with us again and again, implementation after implementation.

Don’t be Fellini. Manage projects with the following patterns:

  • Set the vision and collaborate with people on execution. Listen.
  • Personalize the approach and tasks for the people on the project. Individualize.  
  • Maximize efforts where they matter by minimizing where they don’t. Simplify.

Directing implementation projects is both an art and a game. It is the art of engaging people in an infinite game. Good security projects leave people hungry to play again.

Afterwards

Security is often a story about crime, and criminals often make mistakes even while succeeding. Imagine someone stealing backup tapes to get at stored credit cards, not realizing they were also stealing people’s spreadsheets. In 1975, thieves broke into Technicolor labs and made off with film from 120 Days of Sodom. The heist also swooped up seventy reels of film from Casanova, forcing Fellini to reshoot weeks of material.

A good reminder to classify and protect data according to what criminals value … rather than what a snarky blogger might value.


This article is part of a series on designing cyber security capabilities. To see other articles in the series, including a full list of design principles, click here.

Security Culture needs Security Advocates – Design Monday

Posted by

“Everything is design. Everything.” — Paul Rand (1914–1996)

Paul Rand is behind so many stories this series has covered. The Olivetti Valentine typewriter designed by Ettore Sottsass and used by Dieter Rams in his documentary? Paul Rand did Olivetti’s US advertising. Speaking of Deiter Rams, the Braun shavers that made Rams famous? Paul Rand bought every model. (Though Rand once said he would “buy just for their beauty and then put them in a drawer.”) IDEO, the birthplace of design thinking? Paul Rand did IDEO’s logo. He collaborated on a team with Charles Eames on IBM’s Design Program. I like to think some of that work was in the IBM plaza building that Ludwig Mies van der Rohe designed. The building, by the way, sported the iconic IBM logo which was, you guessed it, designed by Paul Rand.

Paul Rand was instrumental in creating the culture and discipline of graphic design. He taught the next generation at Yale from 1956 to 1985, with a break in the 1970s. Rand was visiting professor and critic at a number of other institutions. Check out the book Paul Rand: Conversations with Students for a view into that work. “What is design?” Paul would often ask. When he wasn’t creating, Rand was instructing, and through instruction, he was creating culture.

Like Paul Rand fostered designers who brought ideas to wider audiences, security leaders need to foster advocates who will bring security ideas to the wider workforce.

We don’t talk much about advocates. A security advocate is a member of the security team who focuses on getting practices into the hands of the workforce. It’s more common for us to talk about security champions. A security champion is a member of the business itself, who collaborates with the security team on best practices. A fully fleshed out security capability has advocates working with champions to interpret and implement security controls. In a well-run security capability, those controls will be usable and widely adopted, because of the partnership of advocates and champions.

To learn more about cyber security advocates and what they need to succeed, check out the “It’s Scary…It’s Confusing…It’s Dull” research paper. These professionals “advocate for systems and policies that are usable, minimize requisite knowledge, and compensate for the inevitability of user error.”

Here are four practices from Paul Rand that we can apply to designing a security advocacy program:

(1) Coach on tangible work, not abstract principles. Rand’s courses were practical not theoretical, with advice given based on the student’s work. He focused stories, literature, examples, and more through the lens of the work at hand.

(2) Coach one-on-one, avoid one size fits all. Paul Rand worked individually with students, and a session on their work “went on as long as was necessary to set the student on the right track and was laced with stories from Paul’s vast career as they were appropriate to the issue at hand. When he worked with students, he poured his heart and soul into it.”

(3) Use short cycle times. Typically, the criticism on individual work in Rand’s courses came weekly. Feedback was quick, specific, and direct. Compare this to many security programs where manager feedback comes at annual reviews.

(4) Encourage personalization. Rand taught designers to build their own set of techniques, their own visual vocabulary, to solve problems. That’s not for the sake of originality. “Don’t try to be original,” Rand often said, “just try to be good.” It’s to develop a sense of the designer’s personal needs and strengths and how to mesh those with the audience’s instincts and intuitions.

When designing a cyber security program, give thought into how leadership will coach advocates. Give thought to how advocates will cultivate security champions. With a nod to Paul Rand, prompt both with a deceptively simple question. “What is security?”

Abacus Photogram, Photography by Paul Rand

This article is part of a series on designing cyber security capabilities. To see other articles in the series, including a full list of design principles, click here.

A Pilot is Purposeful Play – Design Monday

Posted by

A new technology is a new toy. “Toys are not really as innocent as they look. Toys and games are the prelude to serious ideas.”

So said Charles and Ray Eames. The Eames ran a design studio in California (1943–1988) producing architecture, films, furniture. Arguably their most well-known piece was the Eames Lounge Chair. The chair, produced by Herman Miller, ushered in a new era of materials and is a valuable collector’s item today. It’s impossible to overstate this. It was impossible to make furniture that way before Eames. But this story isn’t about a chair.

This story is about a toy elephant.

A decade before the Eames molded wood for a Herman Miller chair, they were playing with molding processes in toys. The result? The Eames Elephant, a toy intricately crafted from molded plywood. The complexity of the elephant was foretold by dozens of unnamed playful experiments. The elephant itself foreshadowed the lounge chair. Without play, without toys, the Eames would never have mastered the underlying skills that produced the later masterpiece.

Playtime is fertile ground for innovation.

The power and necessity of play is a cross-discipline truth. In music, Miles Davis once said “I’ll play it first and tell you what it is later.” In biology, Alexander Fleming often said “I like to play with microbes.” Physics? Andre Geim stated the “playful attitude has always been the hallmark of my research.” The final word on this human condition goes, appropriately enough, to the psychologist Carl Jung. “The creation of something new is not accomplished by the intellect, but by the play instinct arising from inner necessity. The creative mind plays with the object it loves.”

A pilot is purposeful play. We need to pilot ideas and technologies as we frame up the security capability. To get the best work, people doing the pilot must be dedicated, be engaged, and enjoying themselves. As leaders, we clear calendars and make space. We also need to clear bureaucracy and other hinderance to fun. As implementers, we need to clear our heads and reach a state of flow. The purpose of a pilot is to improve our understanding of how things work, and to build underlying skills for what we’ll build next.

See Scale with Philosophy and Methodology for insights on managing the chaos. In the article, I compared Charles and Ray Eames to hackers. I easily imagine them at home in hackerspaces or hacker cons. The Eames embodied the hacker ethic years before “hacker” was even a term. Hands-on. Learning by doing. A strong sense that work, be it design or be it computing, changes the world when we love what we are doing.

The elephant in the room is the best pilot projects won’t look anything like work.

Eames Elephant, Charles and Ray Eames, 1945

This article is part of a series on designing cyber security capabilities. To see other articles in the series, including a full list of design principles, click here.