Flat hierarchies become more and more popular recently, especially in the realms of design and software development. One particular consequence of this appears to be an increase in discussions and exchange of opinions in many situations. While this approach has its upsides, it can also cost valuable work time as well as create tensions within a multidisciplinary team.

As for pirates, they’re a little like these multidisciplinary teams of professionals we enjoy to work in: Differing skills, sharing the will to achieve something and united by the fact that they act outside of common rule sets and will all be equally persecuted for being part of the pirate crew.

Now imagine what would happen if every pirate insisted on their very own opinion where to sail to, or what booty to chase, or only how much rum to be given today. Not much except for long hours of discussion. And the same can be observed with project teams in loose hierarchies.

While the unity and self-determination of the team is one of the essential principles e.g. of Scrum, which we’ve read about here recently, it also creates a problem. Democracy is noble and valid by valuing every single member of a group. But it’s got a weak spot and that’s quick decision processes. When everybody has the possibility to give their opinion, everybody will do so. A set of confident personalities, set up as self dependent democracy will produce elaborate results, but only for a few problems. Eventually some egos will be hurt as well.

In my experience, flat hierarchies are very motivational but lack a moderator to force decisions. This leader must not necessarily be defined as superior boss. He may be part of the team only his profession not being a cannoneer, UI designer or back-end developer but a moderator and decider. Arrrr.

Es ist wieder soweit. Die neue Januar/Februar-Ausgabe des WEAVE Magazin ist erhältlich. Dabei widme ich mich auf Seite 94 einem wichtigen Bestandteil eines jeden User Interfaces. Dem Text.

Was muss ich bei der Beschriftung von UI Elementen beachten? Welche Arten von Meldungen gibt es und wie formuliere ich diese so benutzerfreundlich wie möglich? Dazu habe ich zu Beginn ein kleines Experiment aufgestellt und alle textuellen Inhalte des WordPress-Backend entfernt. Stellt sich nun die Frage, wer kann das noch bedienen? Wie kann ich z.B. den Blogpost an einem gewissen Datum veröffentlichen? Fast unmöglich, ohne die Hilfe des Textes. Nur Umrisse der UI-Elemente und Icons können noch einen groben Anhaltspunkt liefern, sofern der Benutzer mit WordPress bereits vertraut ist.

Mehr zum Thema gibt es wie bereits erwähnt in der neuen WEAVE. Zum Artikel gibt es noch eine Linkliste mit relevanten Seiten zum Thema Text im UI sowie eine kompakte Checkliste, die jeder bei der Umsetzung eines User Interface Textes einmal durchgehen sollte.

Jedes Jahr finden im Herbst über 400 Kreative ihren Weg zur decoded conference nach München. Im Rahmen der Munich Creative Business Week wird nun von 08. – 10. Februar die Fachkonferenz decoded@mcbw in der BMW Welt München veranstaltet.

Unter dem Motto »Discover Interactive Opportunities« richten sich die Organisatoren dieses mal an Manager und Unternehmer, die über drei Tage hinweg exklusive Einblicke in digitale Trends der interaktiven Branche erhalten. In 15 Vorträgen stellen 17 Experten aus den Bereichen Design, Entwicklung, User Experience und Marketing ihre Projekte und Arbeitsweisen vor. Einen Überblick über das Programm gibt es hier.

Unter den Sprechern finden sich unter anderem namhafte Vertreter von Branchenführern wie Google, Adobe Systems, BMW, DATEV oder BurdaYukom (Sprecherübersicht). Das Ambiente der BMW Welt München liefert dabei einen würdigen Rahmen. Dabei wurde die Teilnehmeranzahl exklusiv auf 110 Besucher limitiert. Seien Sie dabei, wenn wir einen Blick auf neue Strategien und Trends werfen.

Programming is an important part of what we do as interaction designers. Be it for prototyping, experimenting or just simplifying things – it’s pretty useful to know your way around coding. And we live in the right time for this kind of development because the tools available are more accessible and more diverse then ever. To give you a little guidance, here’s a summary of the tools/languages we use.

Processing (Java)

Great for general purpose programming. Unobtrusive, fast, and almost endlessly extensible. It is our first choice if we want to quickly sketch something using code. If you’re not into coding already, processing is a great place to start.

OpenFrameworks (C++)

We use OpenFrameworks whenever there’s a lot of computation involved (image manipulation or tracking for example). It’s great especially for installations, because of its speed and its I/O capabilities.

Flash (ActionScript)

Yeah, some people still use this. While we don’t use Flash for web development, it is great as a prototyping tool for both interfaces and installations. The fact that there is a graphical editor included makes it easy to mock up things like transitions or basic interaction. It is also platform independent, so we can develop on a Mac and use it on a Windows computer (the kind of which are often used in installations).

But there is one more aspect for which we love Flash, and that is its handling of text. Both Processing and OpenFrameworks depend on open source libraries to render text. Unfortunately, those libraries are neither fast nor very high quality (probably mostly due to patent restrictions, but that doesn’t matter to the result). Flash has a pretty good and versatile text engine, so it is ideal for the job.

Webkit (HTML/CSS/Javascript)

The glorified new kid. Also a good (and really easy) way to mock up interfaces. One advantage of HTML is that quite often you can transition from prototype to product without rewriting everything. That makes things faster.

We especially love the webkit engine because it can be used everywhere (it’s the rendering engine of Chrome and Safari and is also used in most mobile browsers), has a pretty good feature set (say it with me: 3D Transforms) and also because it has little weird compatibility issues. That makes it great not only for the web, but also for prototyping and – sometimes – installations.

So, while there are other languages we use occasionally (Objective-C, Silverlight…), these are the four most important ones for our everyday work. I’m sure there’s other ways to approach this, but it worked really well for us so far.

Beschäftigt man sich mit dem Design eines Software-Interfaces, machen die UI-Patterns einen wesentlichen Teil der Gestaltung aus und um diese zu definieren, ist der erste Schritt nahezu immer derselbe: »Wie machen das denn die anderen?«

Vorbilder hierzu gibt es reichlich, immerhin begegnen einem die verschiedensten Module – kaum bewusst wahrgenommen – tagtäglich, wo immer man klickt und scrollt. Und sollte die Inspiration noch ein wenig mehr Starthilfe benötigen, so bieten unzählige Seiten einen reichen Fundus an vorgefertigten UI-Bauteilen zur freien Verfügung.

Einmal großzügig bedienen, etwas aufhübschen und fertig ist ein weiteres elegantes Interface, konventionell und einfach (da gelernt) zu bedienen.

Alt(bekannt) ist immer besser

Während man nach einem solchen Vorgehen andernorts von einem simplen Abklatsch, im schlimmsten Fall sogar von einem Plagiat, sprechen würde, ist diese Arbeitsweise im interaktiven Sektor vollkommen legitim. Denn die Vorteile liegen auf der Hand:

Das höchste erklärte Ziel der Interfacegestaltung ist es, die Bedienung einfach, schnell und intuitiv zu gestalten. Und das erreicht man nun mal am sichersten, indem man den Benutzer nur mit bereits Bekanntem konfrontiert. Was der Bauer kennt, frisst er und wenn der Button einen Pfeil beinhaltet, erwartet man ein Dropdown-Menü.

Die Anforderung, an Konventionen festzuhalten, geht sogar soweit, dass das bewusste Kopieren der Konkurrenz nicht nur nicht verpönt ist, sondern tatsächlich ausdrücklich erwünscht wird. So kann man sich sicher sein: wenn das Interface am Ende dem eines bereits erfolgreichen Produkts ähnelt, hat man eine hervorragende Argumentationsgrundlage gegenüber dem Kunden und wird nur in den seltensten Fällen auf Widerstand stoßen.

Die Angst vor neuen Richtungen

Das Gestalten nach dem Strg-C-Prinzip bringt aber nicht nur Vorteile mit sich. Eine Konvention, die sich einmal etabliert hat, wird weitergetragen – ohne dass jemals ihr Sinn hinterfragt oder nach Alternativen gesucht würde.

Ein aktuelles Beispiel, dass es auch anders geht, liefert an dieser Stelle Mac OS X Lion mit seinem invertierten Scroll-Verhalten. Die zu Beginn definierte Scroll-Richtung stammt aus einer Zeit, in der Trackpads noch Science-Fiction waren und so gesehen machte sie damals metaphorisch durchaus Sinn. Doch die Dinge haben sich geändert, ein Trackpad mit Scroll-Funktion gehört zur Standardausstattung eines jeden Laptops und eine tatsächliche metaphorische Übersetzung des analogen ‘ein Blatt verschieben’ zum digitalen Scrollen wäre theoretisch endlich umsetzbar – herangetraut hat sich an dieses Thema jedoch niemand. Zu groß ist die Angst, den Nutzer in einer solch elementaren Funktion zu verwirren. Apple wagte mit seinem neusten Betriebssystem nun schließlich den Sprung und tatsächlich dauert die Umstellung auf das neue System trotz jahre- teilweise sogar jahrzehntelanger Konditionierung nur wenige Tage. Und genau hier wird deutlich, wie das Festhalten an Konventionen und der krampfhafte Versuch, die Lernkurve für den Nutzer so niedrig wie möglich zu halten, die Weiterentwicklung der Interfacegestaltung vollkommen lähmen kann.

Mut zur Freiheit

Natürlich ist es auch keine Lösung, das Rad immer wieder von Grund auf neu zu erfinden. Auf dem bereits Gelernten aufzubauen ist unabdingbar, um eine einigermaßen schnelle Einarbeitungsphase zu gewährleisten.

Aber möglicherweise muss der Weg ja weder Schwarz noch Weiss sein. Während des Studiums wird man sehr darin bestärkt »Out of the Box« zu denken und so unkonventionell zu überlegen wie möglich, frei nach dem Motto »Zurückschrauben geht immer«. In der wirklichen Welt bleibt dafür bei knappen Budgets und engen Zeitplänen leider kaum noch die Zeit. Aber vielleicht findet man ja gelegentlich ein kleines Fenster, um sich mal wieder aus all dem Altbewährten zu lösen. Und mit ein wenig Abstand und dem nötigen Mut zur Freiheit stößt der eine oder andere möglicherweise auf seine ganz eigene neue Scrollrichtung – und die Konvention von morgen.

Seit einigen Tagen ist die neue WEAVE 06.11 am Kiosk erhältlich. In der neuen Ausgabe haben wir wieder einige Inhalte beigesteuert. Besonders hervorzuheben ist das generative Coverdesign von unserer Mitarbeiterin Cora Droysen.

Mehr Infos über das Cover-Konzept findet sich auch im Magazin auf Seite 8. Ein paar Seiten danach (74) erklärt Philipp Sackl in einem Tutorial, wie man mit Hilfe von Processing und Mathematik auf ästhetische Endergebnisse kommen kann. Zusätzlich haben Markus Jaritz und Thomas Gläser fünf verschiedene Unternehmen (Google, Mutabor, precious, UID, WHITEvoid) aus dem interactive Bereich nach ihren Designprozessen und dem generellen Sinn von prozessorientiertem Design gefragt. Die Resultate finden sich auf Seite 98.

Die WEAVE ist an jedem gut sortierten Kiosk erhältlich. Ein Probe-Abo gibt es hier.

Werden wir mit einem Redesign einer Benutzeroberfläche beauftragt, dann fragen wir immer zuerst nach vorhandenen Designs oder Styleguides an denen wir uns orientieren können.

Besteht ein durchgängiges Corporate Design (CD), ist dies für uns der Maßstab für das User Interface (UI). Das Design soll die ästhetischen Vorgaben des Markendesigns konsequent wiedergeben und dadurch die Marke stärken. Dabei ist ist es gleich, ob es um eine Medieninstallation oder eine Benutzeroberfläche geht.

Zum Teil werden wir bei der Entwicklung mit UI-Styleguides konfrontiert, die speziell für dieses eine User Interface entwickelt wurden. Doch oft sind diese meilenweit von der Corporate Identity entfernt und wirken, als ob beim Verfassen des Styleguides mehr Motivation vorhanden war, als bei der Ausarbeitung von ästhetischen und adäquaten Designvariablen für die Benutzeroberfläche.

Markendesign ist Diktatur
Dabei sind Styleguides an sich eine essentielle Größe im Corporate Design. Ist die Marke erst einmal in all ihren Facetten formal beschrieben wird sie so schnell nicht mehr geändert (»Never touch the logo!«). Der Nutzen von Corporate Design ist unbestritten. Stärkt dieses doch den Wiedererkennungswert und visualisiert die Marke über die verschiedensten Medien hinweg.

Der Styleguide ist das zentrale Dokument, welches alle Gestaltungsparameter  wie Farben, Schriften, Abstände, Größen und Relationen beschreibt und zentral zusammenhält. Kreativität ist gut, doch bei der Umsetzung von markenkonsistenten Designs unerwünscht.

Die aufgeweichte Brand im User Interface
Doch gerade im Kontext interaktiver Applikationen beobachte ich immer wieder Designs für Business-Anwendungen und -Portale, die auf der einen Seite die Corporate Styleguides mit Füßen treten und andererseits in ihrer gestalterischen Qualität nicht überzeugen. So kann eine Marke Schritt für Schritt aufgeweicht werden wie Cornflakes, die stundenlang in der Milch schwimmen.

Wie kann es dazu kommen? Eine Erklärung wäre, dass sich die meisten Corporate-Styleguides klassische Medien fokusieren und zum Beispiel Geschäftspapiere wie das Briefpapier bis ins Detail beschreiben. Geht es um interaktive Medien, beschränken sich diese Beschreibungen meist auf die Firmen-Website. Mobile Apps, Desktop-Applikationen und Online-Portale werden dabei oft nicht beachtet.

Ein anderer Grund ist, dass unsere Branche des User Experience Designs noch zu jung ist und wir mit Benutzeroberflächen konfrontiert werden, die teilweise noch von der Programmier-Abteilung einfach auf Basis von Standard-Vorlagen aus Software-Frameworks wie Flex oder Silverlight gebaut wurden.

Es ist die Aufgabe von uns User Experience Designern, das wir Benutzeroberflächen gestalten die einerseits den Bedürfnissen der Benutzer gerecht werden, aber gleichzeitig auch die Markenwerte transportieren.

Styleguides für Corporate User Interfaces
Im Prinzip sind Styleguides ein gutes Mittel zur Kommunikation der grundlegenden Gestaltungsrichtlinien für jegliche Anwendung. Auch User Interface Styleguides bilden da keine Ausnahme – nur sollten sich diese am Corporate Design der Marke orientieren.

Selbst wenn das Interface zu einer Eigenmarke wird wie z.B. BMW iDrive, das multimediale Navigationssystem des bayrischen Automobilkonzerns, kann es sich zumindest visuell in Teilen von der Dachmarke ableiten. Nur so kann eine Markenkommunikation auch konsistent weitergeführt werden.

Der Corporate User Interface Styleguide sollte dabei aus weit mehr als nur Farbe und Schriftart bestehen. Es geht vor allem um die Beschreibung…

• eines durchgängigen Gestaltungsrastern für Interface-Layoutvarianten
• von definierten Größen, Abstände und Relationen von User Interface Elementen
• verschiedenen Zustände (Button Hover, Button Pressed, etc.)
• einer konsistente Icon-Sprache
• wiederkehrende Gestaltungselementen im Gesamtkontext der Anwendung
• eine passenden und schlüssige Szenografie aller „Interface-Darsteller“

Das reine Design einer Benutzeroberfläche bleibt dabei natürlich nur die eine Seite der Medaille. Zu einer guten User Experience gehört grundlegend ein funktionales und für den Benutzer einfach verständliches Interface. Die visuelle Erscheinung einer Anwendung ist zwar das erste, was der Benutzer sieht und was Kunden zuerst fordern, doch das „Schweinchen schminken“ reicht natürlich nicht. Aber das ist eine andere Geschichte…

I am guilty of owning an iPhone 4S and I’m guilty of being excited about Siri. Recently John Pavlus wrote on Fast Company Design that Siri is the ultimate interface: none. So I’m asking myself: if it is the ultimate thing, why does it still feel so artificial to use? Turns out that usability is not so much about the input technology, but rather about trust.

It’s a bloody command line!

If you break it down, Siri is just a software that handles text input. It knows a certain set of commands that it can act upon. This puts Siri into one box with terminals or other language interfaces like Quicksilver or Enso.

The problem with command lines from a usability standpoint is that they are completely opaque – you do not know which commands the machine understands. Even worse, you have no idea what it will do if a command is misunderstood. That means that a command line is either perfect because it understands everything, or it sucks because it is unpredictable. Alas, I have yet to see a perfect command line interface.

Image by The Oatmeal

Siri is still a magnificent piece of technology. It understands more than any other such system (at least when the input language is set to English) and it can do incredible things. But ultimately, a technology is never judged by its merits, but by its flaws (or the lack thereof). Working flawlessly creates trust. But every misinterpreted result makes Siri a little less trustworthy.

»Making life easy« – anders als es das Motto des diesjährigen World Usability Day in München vermuten ließ, stand das Usability-Event dieses Jahr ganz im Zeichen einer Methode  aus der Programmierung. Scrum, die derzeit wohl populärste Agile-Entwicklungsmethode, ist ohne Frage schwer im Trend. Und es scheint momentan für jede Agentur Pflicht zu sein, sie sich in Großbuchstaben auf die Fahnen zu schreiben.

Dass Gestalter dabei scharenweise auf den Zug mit aufspringen (oder von Entwicklern mitgezogen werden) ist da nicht überraschend – ob es auch gut ist, bleibt allerdings die Frage.

Was ist Scrum überhaupt?

Der Grundansatz dieser Methode ist einfach. Er beruht darauf, dass moderne Entwicklungsprozesse so komplex sind, dass eine vollständige Planung zu Beginn des Projekts ohnehin nicht bzw. nur mit vielen Anpassungen während des Arbeitsverlaufs möglich ist. Also macht das »wilde Gedränge« aus der Not eine Tugend und plant in kleinen Schritten; jederzeit in der Lage, den Prozess anzupassen oder zu erweitern. Ein Gesamtkonzept, ein einheitliches Design oder zumindest eine grobe Vorstellung vom Endprodukt – Fehlanzeige.

Das Besondere daran

Im Grunde ist der gesamte Scrumprozess nach dem Baukastenprinzip aufgebaut. Anstatt das ganze Haus zu planen, gibt es eine große Kiste Buntes mit allem, was man sich von dem Heim erwartet. Eine Dachterasse, ein Kamin… und einen Weinkeller wollte man doch auch schon immer mal haben. Ob sich dabei hinter den Gewölbedecken dieses Kellers Marmor oder doch verputzter Rigips verbirgt, ist erstmal völlig irrelevant und es ist dem Keller auch egal, ob der Kamin tatsächlich gebaut wird oder nur ein Traum für den Ruhestand bleibt.

Im Anschluss entscheidet der zukünftige Hauseigentümer über die Priorität der einzelnen Elemente und die Bauarbeiter fangen an zu bauen. Und auch hier greift das Baukastensystem, denn die Arbeiter bauen nur wenige Wochen lang und zwar genau die Elemente, die zu Beginn dieser Zeitspanne ausgemacht wurden, nicht mehr, aber auch nicht weniger. Der Job den Architekten beschränkt sich dabei auf die Herausforderung, dem Ytong-Stein noch etwas Farbe zu verleihen, während er von der anderen Seite bereits mit Mörtel bearbeitet wird. Es kann zwar sein, dass der Bauherr nach einem Monat aufgrund unglücklicher Priorisierung ein wunderschönes Haus mit Kamin, jedoch ohne Fenster hat – doch so oder so, es regnet nicht rein. Und sollte er doch das Licht vermissen, so lässt sich das im Folgemonat beheben, ohne dass dafür das Richtfest auf den nächsten Winter verschoben werden müsste.

Schnell, flexibel, up to date

Wenn man sich die Entwicklung der heutigen Zeit anschaut, scheint es nur natürlich, dass ein solches System einen derartigen Erfolg zu verbuchen hat. Auf Ideen und Veränderungen muss sofort reagiert werden, um mit der Konkurrenz mithalten zu können. Für teils jahrelange Konzeptions- und Entwicklungsphasen scheint kein Platz mehr zu sein.

Und auch im Inhaltlichen bietet die agile Methode sicherlich einige Vorteile. So lassen sich bereits während der Entwicklung Schwachstellen besser erkennen und sofort ausbessern, Elemente können jederzeit unkompliziert hinzugefügt oder entfernt werden und durch die enge Zusammenarbeit wird die Kommunikation im Team gefördert.

Der bedrängte Designer

Während sich Scrum im Bereich Softwareentwicklung nun aber zusehens mehr zu der Methode schlechthin entwickelt, sieht sich wohl jeder Designer irgendwann mit der Frage konfrontiert: Wie lässt sich der Gestalter in diesen Prozess integrieren? Wie erarbeitet man ein schlüssiges Gesamtkonzept, wenn es gar keins mehr gibt? Wie kreiert man ein konsistentes Design, wenn es die Kohärenz zu vermeiden gilt? Sicherlich lässt sich durch konsequente Styleguides und eine entsprechende Flexibilität auf Seiten des Gestalters einigen Problemen entgegenwirken. Weitere Ansätze wären, nur bestimmte Scrumaspekte zu verwenden, die den Designer in gewissen Teilen aussen vor lassen.

Möglicherweise stellt es aber auch einfach den Gestalter vor eine völlig neue Herausforderung und es ist an der Zeit, die eigenen Methoden anzupassen, flexibler zu gestalten und ganz im Sinne der Zeit den effizienten Powerpixler zu erschaffen. Dennoch scheint es, als würde auf diesem Wege nun auch die virtuelle Ebene der Entwicklung und Produktion mehr und mehr von dem Geschwindigkeitshype eingeholt werden, mit dem sich die Produktbranche schon längst arrangiert hat – ob auch die Qualität mit diesem Tempo mithalten kann bleibt offen.

We are are offering an internship position for an Interaction Designer for 6 months starting in March 2012! Just send us your application (Website or PDF) until the end of January 2012. For further details see the whole job description in German:

6 Monate Praktikum als Interaction Designer
(ab März 2012)

Wir sind
ein Münchner Studio für User Interface und Interaction Design. Wir gestalten und konzipieren Benutzeroberflächen für Software und interaktive Medieninstallationen für Messen und Museen. www.envis-precisely.com

Wir bieten

• Einblick in alle Bereiche des interaktiven Designprozesses von Konzeption bis zur prototypenhaften Umsetzung (Skizzen, Wireframes, Mock-Ups…) und fertigem User Interface
• verantwortungsvolle Aufgaben und Mitentscheidungsrecht
• ƒKontakt zu Kunden, Lieferanten und externen Kräften
• ƒjunges Team mit viel Freude an der Arbeit

Du kannst

• deine kreative Ideen einbringen und prototypisch umsetzen
• selbstständig und strukturiert arbeiten
• ƒProbleme lösen und Verantwortung übernehmen
• ƒklassische Werkzeuge wie Photoshop & Illustrator anwenden
• ƒGrundkenntnisse in der Programmierung vorweisen (z.B. Processing, AS3, objectiveC)

After two and a half years of writing for WEAVE Magazine, we finally managed to smuggle a picture of us, a grill and lots of meat into the new issue!

For the better part of this year I worked on installation projects like Streamflow and Holodeck. But in the last couple of weeks I finally had a classic interface project on my desk again.

This also meant that I got the chance to do some interface sketches again; something I almost forgot could be fun. Here are a few things (re)discovered and found interesting.

The Purpose of Sketching

The only reason why I do sketches (and not start directly with, say, wireframes) is to organize my thoughts. When I think about an interface, I always see a few details very clearly in front of me while the big picture is still blurry. Sketching allows me to organize my thoughts, combine them and create new stuff based on older drawings.

Use a Pen you Like

Everyone has a different style when it comes to bringing thoughts to paper and the pen should support that style. I personally need a rather thick pen for drawing and settled with an Edding 1300 felt marker. It is thin enough to write annotations but also thick enough to force me to ignore details in the beginning.

(Paper) Size Matters

I sketch on A3 paper. It is still managable in its size, yet large enough to accomodate a whole group of sketches. I like to draw interesting details next to the basic layout so that I get a clearer idea of the whole composition.

Start Tiny

My sketches grow as my idea of the interface becomes clearer. While the first sketch might be just 5 by 5 centimeters, the last one might fill a whole A3 sheet.

The size of the initial sketches also depends on the pen I use.
The thinner the pen, the tinyer the first sketches should be. This keeps me from trying to figure out every detail in the first sketch and thereby also reduces the fear of doing things wrong.

How do you Sketch?

Do you use similar techniques for sketching or are they completely different? Let me know in the comments!

A prostitute won’t give you free sex just so that she can then charge you for the pillow talk. She won’t give the good stuff away for free.

For some reasons, designers are happy to do so. They create elaborate concepts and plans – sometimes even multiple proposals – pack it all into a high gloss presentation and then hope for the client to be gracious enough to pay them afterwards, when the whole thing needs to be put into practice.

This might work if you are a big agency and you have a lot of time to kill. But it can be lethal for smaller companies or freelancers. If you don’t have a lot of money and resources, you simply can’t afford to do unpaid pitches. Working for free is not going to change your financial situation for the better.

Why do people want pitches, and why is it bad?

1. They don’t know you and they want to make sure that you are worth your money. This means that there is no confidence (and probably limited interest) in your work – which is a bad basis for working together. A good portfolio and some recommendations can turn this ship sometimes.
2. They don’t know what they want and would like to collect ideas upfront. In this case, you’re giving away what you do best upfront. It is pretty common that the winning agency will be told to use some of the ideas of its competitors.
3. They don’t know IF they actually want to do something and they want you to figure out if it is worth it. This is probably the worst form, because more than often it doesn’t even lead to a job for anyone.

In our three years of existence, we never participated in an unpaid pitch. We did two paid pitches in two years – still too many for my taste. We like to charge for our sexy time.