Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Open for the 99%: Designing Inclusive Products ...

Open for the 99%: Designing Inclusive Products + Communities

To get the full slide deck with worksheet + exercises via email, subscribe: http://eepurl.com/cbyywX

## Introduction:

* I’m Vanessa. Welcome to “Open for the 99%”
* which is a series of design principles I’ve developed through fieldwork in open communities over 10 years.
* We’re going to talk about best practices for products and platforms that rely on communities
* Especially in a global context—we’re going to look into how to design for open in underrepresented areas

This is a workshop and there’s a lot of brain power in this room and we’re going to do our best to stitch it together & harvest out experiences.
If you didn’t grab a worksheet, you should, the flow of this is we’ll go through a design principle, then apply it to our communities, then share it out.
You’ll come away with a design framework so you can build stronger products and services.

## Open’s promise and the reality

The landscape: the promise of open source
* Think if you’re in this room you were also excited about the potential of open culture,
* which really seemed to gather steam around 2005-2008, with open poised to infect almost every sector
* with the promise of increased access, decreasing cost and lowering the barrier to entry (that’s how I’d define open culture)
* Vanessa was a believer, these are all orgs that I worked with personally, from content to legal to code

The reality:
* But almost 10 years later, we’re not there yet.
* The reality has not matched the potential.
* As open matures, we’re seeing some patterns that open hasn’t had the impact we’d hoped in locations like Africa, South America and Central and W. Asia
* Examples: Wikipedia = people who are building our global knowledge base are still from privileged places, and we’re missing voices
* And the case is similar with GitHub contributions. And while GitHub is is a different kind of organization, dedicated to commercial interest, the geographical outlay of contributions is similar.
* And the GitHub data is troubling because it means the people who make the software and the people who use the software are really divided
* I’m haunted by the statistic I’ve come across that 1% of the GitHub contributions are made by the continent of Africa, full stop.

Upon reflecting on these data I’ve concluded that there’s a big gap between how open culture talks about itself and what matters to the non-western world

and inclusion has something to do with narrowing that gap

Inclusion
* I want to talk about inclusion from the point of view of business logic: designing for inclusion gets you more customers.
* Inclusion very well may be the key to sustainability for your organization.
* Think about it this way: 50 years from now, 100 years from now—
* who needs to be using your thing in order for it to continue to exist?
* It’s probably customers that aren’t served by your organization right now

## Wide-minded design-framework: a path for growth

A lot of people talk about design and they mean pixels, or they mean post its—when I talk about design I want knowledge to spread.

This is a 5-part pathway to reflect on how you think about growth so you don’t get stuck in the a rut of tunnel vision, or narrow thinking

+ your mission can live on past your contributions.

## Principle 1: Plan for hacks.

What do we mean by hacks?
* Hacks are something we’re all familiar with.
* They’re what we make with paperclips and duct tape and zero time. (a wedge under a table to keep it from wobbling, or my air conditioner teetering precariously out my window).
* In a way design—sleek stuff like apple--has always been for the privileged few—it requires premium resources.
* Hacks are making it work with what you got.
* Trademarks of hacks are that they are fast, cheap and not designed to last very long
* Here’s how that plays out in terms of design:

Hacks are a valuable design principe:
* Flexibility: Chinese characters written on background—these are menu items at a coffee shop of tea and cakes, not because they menu items change, but because the currency fluctuates so frequently
* Speed: Nigeria Danfo buses informal taxi buses without doors, which works for them because those things barely slow down for people to get on and off.

When you’re in the field, look for hacks—they show you what you should be designing for, and for that reason, they lead to incremental improvements and new products.

Example: weather and scooters.

Taking that hacks are a valid path to growth in the non-western world….how can your product create more value by being taken apart and put together again?

* Remixable templates like Bootstrap—something everyone can tangibly build on
* Scratch: color-in coloring contests, a way to increase engagement

## Principle 2: Be Urgent.

What’s something that’s urgent?
* Urgent care to fight illness
* Avoiding authoritarian regimes
* Urgency spurs a call to action from potential community members—it gives them a reason to get involved and a timeframe to get involved.

Now, successful for open platforms and tools speak to an urgent need:
* they focus on fixing what hurts, often using terms that speak to saving time, safety and security
* urgency is a way to speak to something that hurts right now

Here are a few examples of open tools that frame a discrete and urgent need:
* Lantern, which is funded by Open Tech Fund and the State Department, helps folks in blocked countries get access to the web. But see it’s not vague—it’s fast, secure, and easy.
* Ushahadi: speaks to urgency of events and real-time data for citizen journalism (nota bene: made in Kenya by Kenyan residents, which is another dimension of power)

Fixes the hurt of being in the dark and not having information
* Wikipedia: speaks to time saved (don’t actually think this is from Wikipedia)

I want to contrast this against a lot of open cultures’s messages
* which are very fuzzy, and I mean that in terms of not seeing the discrete need
* and appeals to some abstract notion of “feeling good”
* Open does not exist to feel good—it makes things cheaper and so you can have them, yourself
* Feeling good is an outcome of contributing, but it’s not the reason why it exists to an end user

Hearts and flowers are poison for your messaging:
* While I love Lisa Frank, they hearts and rainbows don’t need fixing.
* They aren’t a spur to action, it’s messaging that really does not land with time-strapped users.
* That’s the case when you look at the big open source players
* I have no idea what problem they are solving—let’s take a look

Here are two organizations I have personally built hearts and flowers mesaging for:
* Example: Mozilla and Creative Commons—what is the benefit of their benefit?
* It’s free software and free content that makes your life faster and cheaper…SAY THAT!!!
* Example: Blockchain—especially in West Africa, it’s less compelling because it needs to work yesterday.

## Principle 3: Let’s get to uptake and adoption—Sharing DNA

* What do I mean by “who shares?”
* What I’m talking about is an assumption that’s embedded in nearly every aspect of open culture:
* that sharing is a universal good, and it’s basically the fuel that makes the whole engine of the ecosystem work

Examples of that assumption in practice:
* In order to participate in the meritocracy (which lordy lord has it’s own problems) you need to share your idea with others.
* In order to beta test with users, you have to share an unfinished idea with other people
* Lastly if you an online course, you’ve got to share openly to get the credential

These are a few examples, that, to an end-user, seem like you have to share in order to participate.

In regions without a tradition of decades of intellectual property protection
sharing is not in the DNA.
Sharing is risky.

I should say I AM NOT AN ATTORNEY
* but this map is from some patent attorneys
* it shows patent enforcement world wide
* so you can see why people would be really protective of their work,
* there’s very little IP protection for them to be able to profit from their own work
* http://www.fpapatents.com/resource?id=457

Risk of stealing:
* I learned this lesson when I was giving a talk about community design in IDEA and got interrupted when I was talking about beta testing. A woman informed me that “That was not Nigerian.”
* the solution there was actually working in what I’m calling "practice rounds" —>
* But when I watched a design session with the BBC at CC-Hub,
* the design groups did a rough draft of an exercise—and the prompt was the same for everyone, so no one felt like they were sharing out original work

Another way to think about growth is to spot where and how ideas are spreading already
* In Shenzen, which is one of China’s economic growth areas
* IP takes a backseat to speed of production, speed to market
* So people share their specs, their STL files, because
* The effort and profit is in the execution of the idea, versus it’s potential

## Principle 4: Deeper thinking about scale, and strategy for scale: Nodes before networks

Next we’re going to do some deeper thinking about growth and strategies for scale
* this is important because a lot of what we build is plumbing
* networks, infrastructure, platforms with two-sided markets
* where product language and product approaches are only going to get you so far…

And this is important because, and as idealists we love network effects! We love a Ted talk that’s like
* “imagine a world where knowledge spreads like air”
* “imagine a world where we can teleport over 5 frequencies”
* “imagine a world where a car costs 50 cents a day"

But for network folks,
* (specifically financial network folks, any blockchain lubbers who might be in the room)
* a good portion of those projects need scale in order to be effective.
* But you have to have an existing network to have a network effect.
* networks are made of individual nodes, which you build one at a time
* So before you’re a whole fleet of network effects taking over universes,
* your stuff needs to work at a small scale.

Here are a few strategies from the realm of platform marketing that can help us as we think through this kind of strategy and design...

* Tools for one side of a market first. Opentable developed scheduling tools for restaurants first to get a critical mass, then opened up the other side of the market and end-users by that time had a ton of restaurants already on the platform to choose from.
* Good way of thinking about making the first unit of success smaller
* Follow the rabbit.
* In this case, we are the rabbit, and members will follow us as we build and release items that bring more activity on the platform,
* until we’re basically obsessed with the platform that they’ll never leave.
* Amazon is a pretty good example here of tools that build up trust so users adopt the platform later.

The message here is to think about how you want to assemble your nodes, build up your fleet of individuals before you can weave them into a network.

## Principle 5 which leads us to our last principle, which will help us be forward-thinking in the design of our communities: remove one premise or assumption

What do I mean by assumption?
* I’d say for several community iniatives—clearing government regulation might be an assumption,
* or key partnerships
* Or that your offering has appeal, which it might not

Why remove one premise or assumption?
* Because reflecting on what’s assumed in your future
* will help you be flexibile and consider alternative options

A great example is a pretty famous on in the US:
* In the 40s during WWII planes kept crashing, like 17 a day
* In 1926 when the cockpits of the planes were designed they were for the average piloit—measurements of hundreds of pilots, average height, arm reach etc
* And when the airforce re-measured pilots in the 50s, zero of them were average.

1 single assumption, really crappy outcomes.
You question your assumptions to prevent catastrophe.

Now as a way to stitch together the nodes of our network,
I’m going to ask people to turn to their neighbors, say hi, share what your community or product is,
and one insight from the framework

5 minutes:
* all right, let’s share out
* let’s do 5-6 who is your community or product and what design principle did you think about?

To conclude:
* This approach ties directly to the future of your organization—inclusion and wide-mindedness as a way to keep the lights on
* Also because we want to build things that outlast us, that continue the mission to build the world we want—and band-aids and narrow-mindedness don’t work towards sustained change
* In closing I encourage you to be wide-minded, and to contact me with any follow up ideas or questions

@mozzadrella

May 08, 2017
Tweet

More Decks by @mozzadrella

Other Decks in Design

Transcript

  1. PLAN FOR HACKS BE URGENT DNA OF SHARING NODES BEFORE

    NETWORKS REMOVE ONE PREMISE THE WIDE-MINDED DESIGN FRAMEWORK
  2. PLAN FOR HACKS PRODUCT DEVELOPMENT • HACKS DRIVE GROWTH •

    DELIVER SHORT-TERM FIXES • CREATE MORE VALUE IN PIECES EXERCISE 1: HOW CAN YOUR PRODUCT CREATE MORE VALUE WHEN IT’S TAKEN APART?
  3. H BE URGENT S EXERCISE 2: WHAT IS THE URGENT

    PROBLEM YOUR ORGANIZATION FIXES (RIGHT NOW, TODAY?) MESSAGING • USE WORDS THAT FIX WHAT HURTS. • IF YOU’RE STUCK, TRY FASTER, CHEAPER, MORE SECURE TO START.
  4. SHARING DNA EXERCISE 3: HOW CAN A USER “PRACTICE” IN

    A PRIVATE SPACE IN YOUR COMMUNITY BEFORE THEY PARTICIPATE FULLY? WHERE ARE PEOPLE ALREADY SHARING? GROWTH * FOR REGIONS WITHOUT A STRONG INTELLECTUAL PROPERTY TRADITION, CONSIDER LOW-RISK PRACTICES * LOOK FOR PLACES AND PATTERNS WHERE PEOPLE ALREADY SHARE
  5. FOLLOW THE RABBIT STRATEGY SMALL FIRST PRODUCT LARGER PLATFORM OFFERING

    USER TRUST Platform Revolution: How Networked Markets Are Transforming the Economy-- And How to Make Them Work for You
  6. NODES BEFORE NETWORKS EXERCISE 4: • WHAT IS THE SMALLEST

    DISCRETE UNIT OF SUCCESS YOUR PRODUCT CAN EXPERIENCE? • HOW CAN THAT BE REPLICATED TO UNLOCK FUTURE SUCCESS? STRATEGIES FOR SCALE * ASSEMBLE YOUR NODES & BUILD UP YOUR FLEET BEFORE WEAVING YOUR NETWORK. * THINK ABOUT BUILDING SMALLER TOOLS OR PRODUCTS FOR SMALLER FIRST WINS.
  7. REMOVE ONE PREMISE EXERCISE 5: • WHAT IS ONE ASSUMPTION

    YOUR COMMUNITY WOULD RELY UPON TO SUCCEED? • HOW WOULD YOU ACT IF THAT ASSUMPTION WAS NO LONGER A POSSIBILITY? REFLECT FOR THE FUTURE * REFLECTING ON ASSUMPTIONS HELPS YOU FUTURE-PROOF YOUR DESIGN. * IT’S WORTH IDENTIFYING YOUR ASSUMPTIONS TO PREVENT BADNESS.
  8. PLAN FOR HACKS BE URGENT WHO SHARES NODES BEFORE NETWORKS

    REMOVE ONE PREMISE LET’S PRACTICE