Sobre el idealismo

“¿Qué significa vivir en convivencia unos con otros? Puede resultar algo incomodo, desagradable y en ocasiones hasta miserable, o puede resultar indiferente o lleno de antagonismo, más todo lo anterior se puede presentar en la esfera política sin llegar a la expulsión ni al genocidio. Esta es nuestra obligación, mantenernos dentro de esta esfera a pesar de la rabia que nos embargue o las diferencias que nos apartan.

[…]

De hecho, en la política a veces las cosas que nunca pasan empiezan a suceder. Y debe haber personas que se mantengan dentro de esas ideas, quienes aceptan que son idealistas y que operan en principio opuesto a la política real. Si no existieran estos ideales, nuestra sensibilidad política sería corrupta en el proceso. Quizás uno de los trabajos de la Teoría política y la Filosofía es elevar y mantener estos principios y valores ideales, apoyarlos con voluntad, a pesar de que parezcan imposibles de alcanzar o realizar. El idealismo es entonces un servicio en haras de la convivencia. ¿Qué pasaría si viviéramos en un mundo donde no existieran idealistas? Sería uno muy pobre.”

traducción del texto vía explore-blog de la entrevista con la filósofa Judith Butler sobre su libro Parting Ways: Jewishness and the Critique of Zionism donde aborda el conflicto Israelí-Palestino.

Sistemas de orientación o “Way finding”

Image

Crysis in Parasite Paradise: The work of Realtime Porosity Studio, 2012
Richard Goodwin

El término se refiere al proceso de utilizar la información en un entorno espacial para navegar y llegar a un destino.[1]

Ya sea que naveguemos por un centro comercial, e el campus de una Universidad, una reserva forestal o un sitio web, el proceso de “encontrar nuestro camino” envuelve cuatro etapas principales: Orientación, Decisión de Ruta, Monitoreo de Ruta e Identificación o Reconocimiento del Destino. (Downs, R. 1973)

Orientación  se refiere a la determinación de la localización de uno mismo, en relación con los objetos cercanos y el destino de navegación, se divide al espacio en pequeñas partes usando marcas, o señales para crear un sub-espacio único.  Estos puntos de referencia proveen claves de reconocimiento para identificar y recordar una localidad determinada. Los sistemas de señalización son una manera fácil de comunicar a las personas donde están y hacia a donde pueden dirigirse.

Decisión de Ruta  esta etapa se refiere a la selección de la ruta de destino. Para lograr una toma de decisiones apropiada, hay que minimizar el número de elecciones de navegación y proveer de indicaciones claras en puntos de encuentro clave. Las personas prefieren rutas cortas en vez de las largas (aún y cuando la opción sea más compleja), así que es mejor indicar la ruta mas corta al destino. Las rutas simples pueden seguirse de forma más eficiente a partir de narrativas claras y señales. Los mapas proveen una representación mental mas robusta del espacio y superior a otras estrategias cuando el lugar es amplio, complejo o no ha sido diseñado. Esto funciona en especial en situaciones de conflicto, cuando un sistema de ubicación tiene que adaptarse a un entorno determinado. (ejemplo: escapar de un edificio en una catástrofe). [2]

Monitoreo de Ruta  se refiere al cuidado de proveer señales durante la trayectoria de la ruta elegida que refuercen la idea de estar conduciendo al destino final. Para mejorar el monitoreo de una ruta se recomienda conectar caminos que tengan comienzos, puntos medios y finales claros: estos recorridos deben proveer de un estimado de duración y progreso que lleva la persona al seguir la ruta utilizando señales claras y a la vista, así como un indició de cual será la siguiente locación (locación relativa). En aquellos casos en los que el camino es particularmente largo o el tráfico lo hace demasiado lento, es importante considerar aumentar los puntos de vista de las señales y destacarlas visualmente del entorno. Breadcrumbs[3] -Las claves visuales que destacan cierta ruta- pueden ayudar al monitoreo de la misma, especialmente cuando hay errores, propician la marcha atrás en caso de ser necesario.

Identificación del destino  se refiere al reconocimiento del destino. Para mejorar esta acción se recomienda cerrar los destinos, ya sea que formen rutas sin salida, o la ubicación de barreras para interrumpir el flujo e movimiento en el espacio. Finamente se recomienda dar identidad constante y clara al los destinos finales.

Referencias y Bibliografía

Downs M. R. y Stea, D., (1973)  “Cognitive Maps and Spatial Behavior” en Image and Environment, Aldine Publishing Company. p. 8-26.

Lidwell, W; Holden, K y Butler, J; (2010) Universal Principles of Design 125 Ways to Enhance Usability, Influence Perception, increase Appeal, Make Better Design Decisions and Teach through Design. Rockport Publishers. Beverly Massachusetts. E.U.A.  p. 260

Lynch, K. (1960) The image of the city. MIT Press. Cambridge, Massachusetts. E.U.A.


[1] Kevin Lynch (1960) es uno de los primeros autores que utiliza este término en su libro “The Image of the City”.

[2] Ver el ejemplo de “Way finding by Newcomers in a Complex building” de Darrel L. Butler, April L. Acquino, Alicia A. Hissong y Pamela A. Scott. Human Factors 1993, vol. 35(1), p. 159-173.

[3] El autor hace una analogía de las migajas de pan que dejan los personajes de el cuento infantil Hansel y Gretel de Christian Anderson. Para referirse a las claves visuales que destacan cierta ruta.

“The Power of Networks: Knowledge in an age of infinite interconnectedness. Manuel Lima RSA

Manuel Lima es un “UX designer” (Diseñador de experiencias) de Microsoft Bing, quien explora el poder de la visualización de redes para navegar la complejidad del mundo actual. RSA (Royal Society for the encouragement of Arts, Manufactures and Commerce) es una organización comprometida con la búsqueda de soluciones practicas e innovadoras a los retos sociales […]

La compañía conectada. El libro de Dave Gray

IMG_0065

The average life expectancy of a human being in the 21st century is about 67 years.

Do you know what the average life expectancy for a company is?

Surprisingly short, it turns out. In a recent talkJohn Hagel pointed out that the average life expectancy of a company in the S&P 500 has dropped precipitously, from 75 years (in 1937) to 15 years in a more recent study. Why is the life expectancy of a company so low? And why is it dropping?

I believe that many of these companies are collapsing under their own weight. As companies grow they invariably increase in complexity, and as things get more complex they become more difficult to control.

The statistics back up this assumption. A recent analysis in the CYBEA Journal looked at profit-per-employee 475 of the S&P 500, and the results were astounding: As you triple the number of employees, their productivity drops by half (Chart here).

This “3/2 law” of employee productivity, along with the death rate for large companies, is pretty scary stuff. Surely we can do better?

I believe we can. The secret, I think, lies in understanding the nature of large, complex systems, and letting go of some of our traditional notions of how companies function.

THE COMPANY AS A MACHINE

Historically, we have thought of companies as machines, and we have designed them like we design machines. A machine typically has the following characteristics:

1. It’s designed to be controlled by a driver or operator.
2. It needs to be maintained, and when it breaks down, you fix it.
3. A machine pretty much works in the same way for the life of the machine. Eventually, things change, or the machine wears out, and you need to build or buy a new machine.

A car is a perfect example of machine design. It’s controlled by a driver. Mechanics perform routine maintenance and fix it when it breaks down. Eventually the car wears out, or your needs change, so you sell the car and buy a new one.

And we tend to design companies the way we design machines: We need the company to perform a certain function, so we design and build it to perform that function. Over time, things change. The company grows beyond a certain point. New systems are needed. Customers want different products and services, so we need to redesign and rebuild the machine to serve the new functions.

This kind of rebuilding goes by many names, including re-organization, reengineering, right-sizing, flattening and so on. The problem with this kind of thinking is that the nature of a machine is to remain static, while the nature of a company is to grow. This conflict causes all kinds of problems because you have to redesign and rebuild the company while you also need to operate it – an idea dramatized in an EDS commercial from a few years ago: Building an airplane in flight.

THE COMPANY AS AN ORGANISM

It’s time to think about what companies really are, and to design with that in mind. Companies are not so much machines as complex, dynamic, growing systems. As they get larger, acquiring smaller companies, entering into joint ventures and partnerships, and expanding overseas, they become “systems of systems” that rival nation-states in scale and reach.

So what happens if we rethink the modern company, if we stop thinking of it as a machine and start thinking of it as a complex, growing system? What happens if we think of it less like a machine and more like an organism? Or even better, what if we compared the company with other large, complex human systems, like, for example, the city?

Cities are large, complex, systems, but we don’t really try to control them. In his book Emergence: The Connected Lives of Ants, Brains, Cities and SoftwareStephen B. Johnson quotes complexity pioneer John Holland:

Cities have no central planning commissions that solve the problem of purchasing and distributing supplies… How do these cities avoid devastating swings between shortage and glut, year after year, decade after decade?

No, we don’t try to control cities, but we can manage them well, and if we start to look at companies as complex systems instead of machines, we can design and manage them for productivity instead of collapse.

Cities are not only complex and unmanageable, they are also more productive than their corporate peers. In fact, city productivity inverts the “3/2 rule” that applies to company productivity. As companies add people, productivity shrinks. But as cities add people, productivity actually increases.

A study by the Federal Reserve Bank of Philadelphia found that as the working population in a given area doubles, productivity (measured in this case by the rate of invention) goes up by 20%. This finding is borne out by study after study, and if you’re interested in going deeper, take a look at this recent New York Times article: A Physicist Solves the City.

Okay, you say, but cities are fundamentally different than companies. Just because this works for cities doesn’t mean that it will work for companies. Right?

THE LONG-LIVED COMPANY

Actually there’s some interesting data there too. Back in the early 80’s, right after the revolution in Iran, Shell Oil was concerned about the future of the oil industry, and hence the company. What might Shell look like after oil, they wondered? So they commissioned a study with some very interesting parameters:

1. First, they looked only at large companies with relative dominance in their industries, such as Shell had.
2. Second, they looked only at companies with very long lifespans – 100 years or more.
3. Third, they looked at companies who had made a major shift from one industry or product category to another.

The study was never published, but the findings were detailed in a book: The Living Company by Shell executive Arie de Geus. Shell studied 40 extremely large, extremely long-lived companies, some of which were still surviving after 400+ years. And what do you think they found?

These companies had some common characteristics that have a lot in common with large cities:

Ecosystems: Long-lived companies acted as decentralized ecosystems, tolerant of “activities at the margins.” They were very active in partnerships and joint ventures. In other words, the boundaries of the company were less clearly delineated, and local groups had more autonomy over their decisions, than you would expect in the typical corporation.

Strong identity: Although the organization was loosely controlled, long-lived companies were connected by a strong, shared culture. Everyone in the company understood the company’s values. These companies tended to promote from within in order to keep that culture strong. Cities also share this common identity: think of the difference between a New Yorker and a Los Angelino, or a Parisian, for example. At the Dachis Group we like to call this common culture hivemind.

Active listening: Long-lived companies had their eyes and ears focused on the world around them and were constantly seeking opportunities. Because of their decentralized nature and strong shared culture, it was easier for them to spot opportunities in the changing world and act, proactively and decisively, to capitalize on them. At Dachis we sometimes call this dynamic signal (watching and listening) and metafilter (information leading to decisive action).

Although we tend to design companies like machines, we instinctively and intuitively understand that, in the end, companies are not made of cogs, levers and gears. In the end they are made out of people. For top management, it would be wonderful if we could put our business strategy into the machine, push a button and wait for the results. But it doesn’t work that way. You have to put your strategy into people.

DESIGN BY DIVISION

Historically we have designed companies like machines – by division. We constructed the org chart to divide the big chunks of work and separate them from each other: Finance, Sales, Operations. We designed the work flows that process inputs into outputs: raw materials into products, prospects into customers, complaints into resolutions.

As we design this kind of company – the divided company – we need to separate functions, which means people may not always have a sense of the larger thing they are working on. They get very good at one of the tasks but lose touch with the larger picture. So we have to design rigid policies and procedures, so people will function efficiently and so they won’t interfere with each others’ work.

The problem comes with scale. As the number of employees grows, the profit per employee shrinks. It’s a game of diminishing returns. Efficiencies of scale are balanced out by the burdens of bureaucracy. Overhead costs increase with size. The resulting need for control is what eventually kills a business.

DESIGN BY CONNECTION

But today we finally have the tools to manage companies like the complex organisms they are. Social Business Design is design for companies that are made out of people. It’s design for complexity, for productivity, and for longevity. It’s not design by division but design by connection.

To design the connected company we must focus on the company as a complex ecosystem, a set of connections and potential connections, a decentralized organism that has eyes and ears everywhere that people touch the company, whether they are employees, partners, customers or suppliers.

Social Business Design is a new discipline but some basic rules are already emerging. And these emerging rules have less in common with traditional business design and more in common with urban design and city planning. It’s not about design for control so much as design for emergence. You don’t control a complex system, but you can manage its growth.

Social Business Design is a new field but here are some things that work:

Understand the culture: A company is like a city in many ways. First and foremost, a city is about the people who live and work there; it’s an expression of their collective culture. And before you can start your path to the connected company, you first need to understand the culture (or cultures) that are already there, so you can look for ways to enhance and strengthen that shared identity.

Start small. Urban designers might look at maps or aerial views as they make their plans, but the life of a city happens at street level. As you initiate social programs, think of them as if you are designing a city street. A successful street, first and foremost, is filled with people. The last thing you want is a whole bunch of large, urban areas with no people in them. So start small, because the smaller the space is initially, the faster it will fill up with people. A good way to start is with an organization-wide project or initiative that requires participation from a number of people across the company. This gives you a cross-section of ideas and perspectives to look at as you plan the next stage.

Spaces need owners. Again, think of the city street: every business or building has an owner. The sidewalks have owners – typically every business at street level “polices” their stretch of sidewalk. And even the street has owners – the street sweeper, the cop on the beat. In the same way, make sure that every online space you create has someone positioned to take care of it, to keep it safe and clean.

Every person needs a place. In the same way that public spaces need caretakers, every person needs a place to live; somewhere they can put their stuff. As you build your social business, make sure that every single person has a place where they can see their stuff: their projects, the links they want to get back to, the documents they have created, their role, qualifications, expertise and so on.

Jumping-off points. A good city street offers opportunities that are unanticipated but serendipitous. The promising side-street. The sound of music coming through an open door. As you design for connection, think about how you might create those unexpected, but delightful, surprises. Every time someone visits an online space, there’s an opportunity to offer them an opportunity to explore something new.

Watch, listen, adjust and adapt. Design by connection is not a top-down activity so much as bottom-up. Complex systems just don’t work that way. In a complex system, you need to pay attention to small things and make little adjustments along the way. Pay attention to the culture, and watch how people react to the tools you provide. Are they using something in a different way than you expected? Find out why and see if you can enhance that. And what are they ignoring? If they’re not using something you expected them to use, go talk to them and see if you can figure out the reason.

The typical company has a very short life, from 15 to 50 years. But cities – and some companies – live much longer lifespans: from hundreds to thousands of years. Wouldn’t you like that for your company?

UPDATE: The book “The Connected Company” is now available on Amazon!

5 day Design Process Workshop (Parte 2)

From Google Ventures, The 6 Ingredients You Need To Run A Design Sprint

WRITTEN BY: 

GOOGLE VENTURES’ JAKE KNAPP LISTS THE PEOPLE AND THINGS YOU’LL WANT ON HAND TO START TACKLING A BIG DESIGN CHALLENGE.

2 Comments
 
inShare
 

[Editor’s note: This is the second post in a seven-part guide on how to conduct your own Google Ventures’ five-day design sprint. Read the first part, on why you should conduct a sprint, here. See more at Google Ventures’s site, Design Staff].

At the Google Ventures Design Studio, we have a five-day process for taking a product or feature from design through prototyping and testing. We call it a product design sprint. This is the second in a series of seven posts on running your own design sprint.

Now that you know what design sprints are good for, you’ll need a few important ingredients to make yours successful. Start with a big, important problem; pitch it to your team; and schedule a user study before you even start. Get the right people and the right supplies in a room and you’re on your way to a successful design sprint.

 

 

1. PICK A BIG FIGHT

 

The first thing you need is an important design problem, and if you work at a startup, chances are good you probably have one lying around the office. Maybe more than one. It might be something big, like defining your product for the first time, or a big redesign or new feature. Or it might be something detailed, like improving conversion on a single user action. It just has to be really important to the company, and it has to be something you’re struggling to start or to make progress on–otherwise it can be difficult to get the other people you’ll need involved.

As long as it’s an important problem, it’s perfect for a design sprint. It’s OK if you don’t feel ready to start on it yet. No matter how overwhelming or ambiguous, you’ll be able to cut a big swath through the jungle of possible solutions.

 

2. GET THE RIGHT PEOPLE

 

The ideal sprint team is between four and eight people, but you can get by with more or fewer than that. Just make sure you have at least one:

• Designer: If your startup doesn’t have a designer yet, try to bring in a ringer.

• CEO: At a small startup, the CEO is the key decision-maker and needs to participate in order to get an actionable solution out of the sprint. At a bigger company, you’ll still need buy-in and it’s best to include the CEO, but if they can’t be there the whole time, you can bring them in at key decision-making moments.

• Product manager: The PM (or whoever is filling this role) will likely need to implement the solution that comes out of the sprint.

• User expert: The person on the team who has the most direct contact with customers often has great input, and can be the lead on user testing.

It’s also great to include:
• Engineer
• Marketer
• Anybody else who’s interested

 

3. SCHEDULE THE USER STUDY BEFORE YOU HAVE ANYTHING TO TEST

 

Once you know when you’re going to do the sprint, recruit users and schedule the user studies for the last day of the sprint. This is a bit terrifying: you haven’t even started to talk about the problem, let alone design solutions, and people–outsiders!–are going to come in and need to be shown something. This hard deadline, even though it’s artificial, will help you move faster and make tough decisions to focus your work throughout the sprint.

 

4. FIND A FACILITATOR

 

Pick someone to be the facilitator of the sprint. The facilitator is going to be responsible for managing the sprint and moving things along. They need to be confident leading a meeting, including synthesizing discussions and telling people it’s time to stop talking. They also need to be comfortable with not getting to participate as much in the actual design work, because facilitating is a lot of work. Since you’re the one reading this, you may be a good candidate–but it’s always easiest if the facilitator is an outsider. See if you can get a friend from another company to help out.

5. PUT IT ON THE CALENDAR

Clear everybody’s schedule for five consecutive days. It’s also very important to have a dedicated room for the duration of the sprint, usually a conference room with lots of whiteboards.

Much of the magic in design sprints comes from the sense of urgency. By their very nature, startups always feel time-constrained; the short, focused time of the sprint adds another constraint.

 

6. GATHER THE INGREDIENTS

 

 

Luckily, you don’t need anything fancy to run a sprint. Here’s everything I use:

• Sticky notes: I like the yellow 3×5 size.
• Drawing pens: Any standard black or blue pen is probably fine. I likethese, or you can get these for extra credit.
• Whiteboards: If your war room doesn’t have a lot of whiteboard space in it, find another war room or some rolling whiteboards, or heck, get someIdeaPaint and get busy.
• Whiteboard markers: I like to use these instead of Sharpies because they’re so versatile. Buy some good ones and be sure to have enoughblack markers for each person in the sprint.
• Dot stickers: for voting. You want something small with uniform color.Post-It brand dots are great.
• 8.5 × 11 blank copy paper: Nothing special, just have a pack of this on hand.
• Time Timer Clock: Optional, but totally awesome, see here. I guarantee you’ll find it useful during the sprint, and probably during regular meetings afterward.
• Snacks: You’ll need caffeine and food handy. Trail mix, bananas, and dark chocolate covered raisins have proved especially popular at our sprints, although it is possible that it’s just me eating all of it.
• Sticky stuff: You’ll need to stick your drawings and storyboards on the wall. This removable gummy material is inexpensive and works great, with less fuss than tape.

OK, the stage is set. Now it’s time to start the sprint.

Stay tuned for tomorrow’s post, in which we’ll explore the exercises we use on the first day of a sprint.

5 day Design Process Workshop (Parte 1)

How To Conduct Your Own Google Ventures Design Sprint

WRITTEN BY: 

TO MENTOR 150 STARTUPS IN ITS PORTFOLIO, GOOGLE VENTURES DEVELOPED A FIVE-DAY DESIGN PROCESS. HERE, THE METHOD’S MASTERMIND, JAKE KNAPP, DETAILS HOW YOUR COMPANY CAN RUN ITS OWN SPRINT TO SOLVE A BIG PROBLEM.

8 Comments
 
inShare
 

Editor’s note: This post is part of a seven-part series originally published on Google Ventures’ site, Design Staff.

At Google Ventures, we do product design work with startups all the time. Since we want to move fast and they want to move fast, we’ve optimized a process that gets us predictably good results in five days or less. We call it a product design sprint, and it’s great for getting unstuck or accelerating projects that are already in motion.

I’ve planned and run over 40 of these sprints, first with teams at Google and now with startups in the Google Ventures portfolio. To give you an idea of what one looks like, here’s a project we did with CustomMade:

Over the next several posts, I’ll be sharing a DIY guide for running your own design sprint.

Before the sprint: Prepare 
Get the people and things you need.

Day 1: Understand 
Dig into the design problem through research, competitive review, and strategy exercises.

Day 2: Diverge 
Rapidly develop as many solutions as possible.

Day 3: Decide 
Choose the best ideas and hammer out a user story.

Day 4: Prototype 
Build something quick and dirty that can be shown to users.

Day 5: Validate 
Show the prototype to real humans (in other words, people outside your company) and learn what works and what doesn’t work.

 

If you think you’ve heard of this model before, well, you’re right. It’s based on the design thinking structure championed by Ideo and Stanford’s d.school. However, I’ve experimented and tweaked the process a bunch over the last few years. The version I’m going to share works especially well for startups.

 

WHAT DOESN’T WORK ABOUT BRAINSTORMING

 

I’m a big-time process nerd. Several years ago, I started experimenting with product design processes at Google. At first, I ran group brainstorming workshops inspired by the Ideo approach. Group brainstorming, where everyone shouts out ideas, is a lot of fun. At the end of a workshop we’d be tired, in good spirits, and the proud owners of a big pile of sticky notes. But the new ideas we came up with didn’t go anywhere. It’s not that we were coming up with dumb ideas–most of the ideas were actually pretty good. Yet still, better ideas were coming from somewhere else. But where?

In my experience, the most successful ideas tended to come from individuals, not groups. The ideas took some individual heads-down work time to develop, too. I ran a lot of workshops before I realized this, so if it seemed obvious to you from the beginning, I hope you’ll cut me some slack.

To make matters worse, my workshops were choosing the winning ideas by consensus. But consensus doesn’t always pick the bold ideas, the unique ideas, or the ideas with design integrity. Consensus tends to compromise.

There were a lot of good things going on in the workshops: focusing a team on one project, considering a range of ideas instead of just one, working on paper, and more. But I decided my method was fundamentally flawed. I was getting good-but-not-great ideas through group brainstorming, then choosing winners by consensus. I knew that wasn’t working, but at first, I wasn’t sure what to do about it.

 

THE MAGIC OF CONSTRAINTS

One day I noticed something about my own design projects. The best work happened in short bursts, when I was under a deadline. One example was Gmail Priority Inbox, where we spent four weeks experimenting with different design prototypes. There were hundreds of internal dogfood users signed up to try a new experiment each week, so I had to move fast. By the end of the four weeks, I’d figured out which things worked, and saved months of noodling.

Another example was the project that became Google+ Hangouts. It started as a side project with two Googlers in the Stockholm office. I was visiting for only two days, so I designed as fast as I could. By the end, we had a working prototype that we could start using for our team’s meetings.

In both of these cases, I worked far more efficiently than I ever did in my normal day-to-day routine or in any of my brainstorm workshops. So what was different? I had time to focus and develop ideas on my own, not shouting and pitching the way I would in a group brainstorm.

But I also didn’t have too much time. I couldn’t afford to overthink things or get caught up in urgent but less important issues, the way I often did on normal workdays. And the people I needed to help me–engineers and product managers–were also focused on the project.

There was something magical about a tight time constraint combined with individual work, prototyping, and quick user feedback.

 

ADAPTING IDEO-STYLE WORKSHOPS TO WORK AT GOOGLE

 

I decided to try linking an Ideo-style “how might we” workshop to a few days of uninterrupted design time to execute the best ideas. In that very first sprint, designer Jason Cornwell roughed out the idea for the Gmail people widget. I knew I was on the right track.

I focused full-time on running design sprints with various teams at Google. I switched from group ideas to individual ideas and gave people more time to develop those ideas before getting feedback. I tried a bunch of critique and decision-making exercises that didn’t rely on consensus and chose a handful that worked best.

I got a lot of practice: I’d jump from team to team within Google, for a few days or a week at a time, leading sprints for projects like Chrome, Ads, Commerce, Apps, Search, and Google X. It was exciting. The designs were launching, and lots of teams started to run the process on their own.

10X FASTER: RUNNING DESIGN SPRINTS AT STARTUPS

When I joined Google Ventures, I thought I had sprints all figured out. But I quickly realized I had a lot to learn. The process had to be changed to reflect the differences between a large company like Google and the startups in our portfolio. For example, at Google, it was easy to get three or four designers together for a few days. At a startup, they might be lucky to have one. So we needed design and critique processes that engineers and CEOs could do as easily as designers.

Startups want to get their product out there quickly and learn what’s working, but it’s costly to launch–you have to write more code, fix more bugs, and handle more issues than with a prototype. So we compressed the sprint cycle even further to get companies faster feedback. I ditched polished Photoshop mockups in favor of quick-and-dirty Keynote prototypes. Michael Margolis tied in his lightning-fast research techniquesto deliver us next-day feedback.

We’re still learning, but we’ve run enough sprints to be confident the process works well.

Stay tuned to this series, and please give me your thoughts along the way–I’m always looking for more tricks to improve what we do. What processes do you use to get good design results? What helps your company move faster?

Read the second post here.

http://www.fastcodesign.com/1672887/how-to-conduct-your-own-google-design-sprint