Category: Was ist?
Home / Allgemein /
Schnell mal prototypen mit weld.io

Bewertet: Das Rapid-Prototyping Tool von weld.io

 

Beschäftigt sich viel mit dem Thema „plattformübergreifendes Layout“ oder responsive Design, hat man wahrscheinlich schon diverse Tools unter seinen Fingern gehabt. Von Papier-Skizzen bis zu Fireworks Wireframes. Die einen schwören auf Photoshop, die anderen auf Indesign und für Puristen tut es dann auch mal Powerpoint. Alle Werkzeuge haben allerdings eines gemeinsam: Man kommt nicht umhin jedes Layout im Browser zu testen und das bedeutet ab einem gewissen Stadium einen Fronend Prototypen zu entwickeln. Idealerweise ist das zwar nicht notwendig ( wenn man sich man sich an die prototypische Entwicklung einer App oder einer Seite hält) aber vielen Agenturen, Designern und Auftraggebern ist dieser Prozess noch fremd, da sie davon ausgehen dass das Design die Vorgabe für die Technik und die Umsetzung bestimmt.

An genau diese Protagonisten richtet sich das Browser basierte Layouttool von weld.io. Nach der kostenlosen Registrierung hat man die Möglichkeit ein (1) Projekt anzulegen. Mehr Projekte kosten dann Geld. Entweder man kauft sich für 10$ zwei zusätzliche Projekte oder man schließt ein monatlich kündbares Abo ab, das mit Kosten von 29$/Monat zu Buche schlägt.

Das sehr simple und intuitive Interface hält die Lernkurve erstaunlich flach. Dazu trägt auch die Implementierung diverser bekannter Tastenkürzel bei und man fühlt sich direkt wohl. Die am unteren Browserrand angedockte Werkzeugleiste bietet einen mehrstufigen Zugriff auf Werkzeuge, Element-Bibliotheken und Funktionen. Erstellt man beispielsweise ein Element, erweitert sich die Leiste automatisch um weitere Einstellungsmöglichen für das ausgewählte Element.

Bildschirmfoto 2015-02-25 um 11.23.53

Die Werkzeugliste von weld.io

Voreingestellt ist die „Desktop“ Ansicht. Wechselt man auf „Tablet“ oder „Phone“ verkleinert sich der Darstellungsbereich entsprechend und wie von Zauberhand rearrangieren  sich die Elemente.

Drei Layout Stadien

Drei Layout Stadien

Kommt es in den einzelnen Layouts zu Darstellungsfehler oder werden Elemente ungünstig dargestellt kann man  den Bearbeitungsmodungs von „Editing All“ zu beispielsweise „Editing Phone“ wechseln. Alle hier vorgenommenen Änderungen wirken sich dann nur auf das ausgewählte Format aus.

Schnell, schneller, weld

Da ich schon einige Tools ausprobiert habe die von sich behaupten den Entwicklungsprozess zu beschleunigen, war ich Anfangs etwas skeptisch. Aber nachdem innerhalb von 30 Minuten ein testbares Layout stand, war ich begeistert. Innerhalb von 1-2 Stunden sind mir die Funktionen in Fleisch und Blut übergegangen und die Tastaturkürzel machen das arbeiten mit der Leiste fast schon obsolet.

Schnell online testen

Kritik kann man durchaus an der Tatsache üben, das meine Daten online und auf einem fremden Server liegen. Vertraut man den Jungs aus Schweden bekommt man mit der „share“ Funktion ein praktisches testing-Tool an die Hand. Ich kann das Layout schnell und unkompliziert an Kunden, Arbeitskollegen oder Tester schicken, die mir noch im Entwicklungsprozess, Feedback unter Realbedingungen geben können. Dabei kann ich das Projekt wahlweise mit E-Mail oder als SMS (!) verschicken.

Auch der Support ist schnell

Nach intensivem arbeiten ist es zu vereinzelten Bugs gekommen über die man hinwegsehen kann. Ein einziger kapitaler Fehler ist mir allerdings übel aufgestoßen. Anscheinend gibt/gab es bei manchen Projekten Syncronisationsfehler, was dazu führt das aus heiterem Himmel ein alter Stand des Layouts angezeigt wird und es keine Chance gibt zu dem neuen Layout zurückzukommen. Nachdem ich mich beim Support beschwert hatte, bekam innerhalb von 10 Minuten eine Antwort, eine Entschuldigung, 3 Monate Pro Account und die Bitte um Mithilfe zur Lösungsfindung. Cool.

Ist das was für mich?

Wenn man, wie ich, gerne etwas neues ausprobiert und alle Bedenken erstmal hintenan stellt kann man sich wahrscheinlich sehr schnell für dieses Tool begeistern. Ist man etwas reflektierter als ich, gibt es doch einige Bedenken. Eine pro und kontra  Liste helfen dann vielleicht zu entscheiden.

Pro

• schnelle Ergebnisse bei 100% individueller Gestaltung
• Überall verfügbar
• enorme Zeitersparnis
• Das Konzept „responsive Design“ wird gut vermittelt

Contra

• die Arbeitsdaten liegen nicht offline bei mir
• Internet Verbindung ist notwendig
• Brisante Projekte liegen online und sind theoretisch für jedermann zugänglich.

Fazit

Ich bin von dem Tool begeistert. Es macht jetzt schon einen brauchbaren Eindruck und hat die Chance meine derzeitigen Stammspieler zu ersetzen. Wird der Funktionsumfang, wie angekündigt, weiterentwickelt und bekommen sie die Fehler in den Griff , so ist weld.io ein ernster Konkurrent zu etablierten Produkten. 
Kreativ & agil

Im Zuge des Projekts „ICE Entertainment Portal“ bin ich mit einer Arbeitsweise konfrontiert worden, die mir zwar bekannt war aber auf die ich mir noch keine differenzierende Meinung bilden konnte. Mittlerweile ist diese Methode auch in der Kreativbranche angekommen und nach fast 2 Jahren Projekterfahrung kann ich ein kleines Fazit ziehen. Die Rede ist von dem agilen Prozess SCRUM. 

Was ist Scrum?

Die meisten Kreativen und Kunden arbeiten nach dem Wasserfall Prinzip. Man bekommt das Briefing, entwickelt ein Konzept, stimmt es ab und setzt es dann technisch um. Nun verdienen immer mehr Unternehmen mit ihren Services im Internet Geld und immer mehr Unternehmen bieten ähnliche wenn nicht sogar redundante Leistungen an. Es gibt unzählige Apps und Internetseiten über die ich mir eine Pizza bestellen kann. Die Frage welchen Service ich nutze ist nicht mehr ganz so trivial? Lieferando? Lieferheld? Pizza.de?

Die Usability und die User Experience werden jetzt zum wichtigsten Alleinstellungsmerkmal.

Jetzt könnte man zwar argumentieren das die Emotionalität und die damit einhergehende Identifikation mit der Marke schon ausreicht, aber spätestens wenn der Bestellprozess 2 Klicks mehr braucht wechsle ich den Service, denn das spart Zeit. Einmalig nur 8 Sekunden aber nach 100 Pizzen sind das immerhin 13,3 Minuten meines Lebens. Die Usability und die User Experience werden jetzt zum wichtigsten Alleinstellungsmerkmal. Leider weiß die Agentur davon nichts, da sie mit dem Kunden des Auftraggebers nichts zu tun hat. Der Auftraggeber erfährt von diesem und vielen anderen kleinen Problemen erst wenn das Produkt am Markt ist und das ist für viele Online Startups oder Services ein KnockOut.

Im Gegensatz zum klassischen Wasserfall Prinzip, versucht Scrum einen Prozess transparent, überprüfbar und anpassbar zu machen. Der Kunde bekommt schon während des Prozesses die Möglichkeit sein Produkt zu testen, zu verändern und anzupassen. Merkt er während des Prozesses dass das Produkt eigentlich schon ausreicht um live zu gehen, kann er ihn unterbrechen und alles überflüssige eliminieren. Kleinkonzepte können schon früh überprüft und gegebenenfalls verändert werden.

 So geht Scrum

Voraussetzung  für Scrum ist ein Kunde der will und eine Agentur die kann. Bei Scrum gibt es Rollen die das Scrum-Team bilden. Es ist essentiell das diese standardisierten Rollen eingehalten werden, da es sonst zu immensen Komplikationen im Projektablauf kommen kann. Folgende Rollen gibt es:

Product Owner (PO)

Der Product Owner repräsentiert den Projektverantwortlichen. Er steht dafür gerade was das Team produziert. Er ist für das Produkt Backlog verantwortlich (eine Sammlung der Userstoieres) und priorisiert diese. Am Ende jedes Sprints (Zeitraum in dem Userstories umgesetzt werden)  nimmt er diese ab und gibt sie frei oder lehnt sie ab. Der Product Owner muss nicht zwingende der Kunde sein, repräsentiert aber innerhalb der Agentur den Kunden. Er steht im ständigen Kontakt mit dem Auftraggeber und dem Scrum Master. Er ist verantwortlich dafür dass das Projekt nach jedem Sprint live gehen könnte und optimiert mit seinen Entscheidung den Business-Value (Wie rentabel ist das Produkt) und den Customer-Value (Wie nützlich ist Produkt). Der PO mischt sich niemals in den Arbeitsablauf ein oder versucht das Team zu beeinflussen.

Scrum Master

Der Scrum Master ist Moderator(!). Er hat keinerlei Entscheidungsgewalt und beeinflusst Entscheidungen nur mit Tipps und dann nur äusserst zurückhaltend. Er ist verantwortlich für den Prozess und räumt Hindernisse aus dem Weg. Er hat das Backlog im Blick und dient als Schnittstelle zwischen Team und Product Owner. Idealerweise ist er jemand der sich mit dem technischen Aspekt auskennt aber nicht an diesem beteiligt ist. Er hält dem Team den Rücken frei und tritt in Konfliktfällen als Mediator auf. Er ist weder Teamleiter noch Chef.

Scrum Team

Der Scrum Team ist ein interdisziplinäres Team. Es wird zwar darüber diskutiert ob das sinnvoll ist hat aber einen durchaus gerechtfertigten Grund. Fällt jemand im Team aus, kann ein anderer zweitweise seine Position einnehmen. Nach meiner Erfahrung ist es sinnvoll das jeder alles kann aber zusätzlich eine starke Profilkompetenz mit sich bringt. Ein Team besteht aus 5-10 Personen (z.B Designer, Texter, Frontendentwickler, Backendtwickler, Systemarchitekt, Tester). Das Team organisiert sich selbst und hält täglich ein Daily Scrum (5-10 Minuten) um sich gegenseitig auf den aktuellen Stand zu bringen. Es ist verantwortlich nach jedem Sprint ein Increment of Potentially Shippable Functionality abzuliefern. Das Team ist steht in der Hierarchie weder unter noch über dem PO oder dem Scrum Master.

Vision

Der PO definiert eine Vision der alle Teammitglieder folgen. Eine Vision für eine Pizza Lierferapp wäre z.B.: „Immer einen Klick schneller als die Konkurrenz“. Dieser Satz ist der rote Faden der sich durch die Entwicklung des Produktes zieht und worauf man immer wieder zurückgreift um sicherzustellen das man auf der richtigen Spur ist. Nun wird ein sehr grobes technisches Konzept aufgestellt um die nötige Infrastruktur zu definieren. Das technische Grobkonzept ist kein Bestandteil im klassischen Scrum Prozess, bietet aber den Vorteil Abhängigkeiten im Vorfeld zu klären die den Prozess lahmlegen könnten.

Userstories

Ist das gemeinsam geklärt worden, kommt der wichtigste Teil – die Userstories. Eine Userstory beschreibt einen Wunsch aus der Sicht des Nutzers.* „Als Nutzer möchte ich eine Pizza mit meinem iPhone bestellen“. Die Story sollte so genau wie nötig und so vage wie möglich sein. Der PO präsentiert diese Story zusammen mit den anderen priorisierten Stories im Sprint-Planning, das vor jedem Sprint stattfindet. Darin entscheidet das Scrum welche Stories umgesetzt werden. Das Bahnprojekt hatte insgesamt über 450 Stories und in jedem Sprint wurden, je nach Kapazität und Leistungsfähigkeit des Teams, 3-6 Stories umgesetzt. Um die Einschätzung zu erleichtern hat das Team Kapazitätspunkte, Kappa, die es demokratisch auf die Stories verteilen kann. Die Kappa kann sich erhöhen je eingespielter das team wird.

* Die Userstories werden vom PO zusammengetragen und im Backlog gesammelt. Viele Scrum Projekte visualisieren den Scrum-Prozess an einer Wand und sammeln die Stories auf Postits, sodass jeder jederzeit den Überblick hat wie der Projekt Status ist.

Sprints

Alle Stories werden in sogenannten Sprints umgesetzt. Ein Sprint ist ein fest definierter Zeitraum (time boxed). Üblicherweise 14 – 31 Tage. Zum Start des Projekts wird die ungefähre Anzahl an Sprints eingeschätzt, die das Projektteam braucht um das Produkt abzuschließen. Ein Sprint besteht aus 4 Phasen. Dem Sprint-Planning, der Umsetzung, dem Sprint-Review und der Retrospektive. Das Review dient dazu die umgesetzten Userstories zu präsentieren. Der PO entscheidet an dieser Stelle ob eine Story den definierten Akzeptanzkriterien entspricht und lehnt sie entweder ab oder nimmt sie an. Lehnt er sie ab fließt sie wieder in den Backlog und muss in dem nächsten Sprint fertiggestellt werden. Das Scrum Team hat sich verpflichtet bei jeder Review ein „Increment of Potentially Shippable Functionality“ zu liefern, ein releasefähiges Teilprodukt.

Logischerweise ist das meist nach dem ersten Sprint nicht der Fall aber wenigstens nach drei Sprints sollte ein Produkt stehen das man veröffentlichen kann.

Auch Apple setzt Produkte nach dem Scrum-Prinzip um. Die Idee dahinter nennt sich First-to-market-Strategy.

Hier ein Beispiel: Auch Apple setzt Produkte nach dem Scrum-Prinzip um. Die Idee dahinter nennt sich First-to-market-Strategy. Als erster am Markt sein. Das erste iPhone war Anfangs nur ein Prototyp. Die Apps, der Appstore und die heutigen Features lagen noch alle im Backlog. Sie waren geplant aber noch nicht implementiert. Aber um als ersten am Markt zu sein hat man sich entschlossen schon den ersten realeasefähigen Prototypen zu verkaufen. Der Vorteil liegt klar auf der Hand. Man platziert sich beim Kunden und man kann testen welche Features ankommen und als nächstes implementiert sollten.

Retrospektive

Nach jedem Sprint trifft sich das Team und bespricht was gut gelaufen ist und was nicht. Wird dabei ein  Problem festgestellt, wird es identifiziert, eine Lösung vorgeschlagen und ein Zeitraum sowie eine Person die es aus dem Weg räumt definiert. Das löst nach jedem Sprint die Spannungen und macht das Team produktiver.

Fazit

Scrum ist modern und macht Spaß wenn man sich an die Regeln hält. Es entspricht dem Geist der heutigen Startup Pioniere. Für Agenturen bietet es die Möglichkeit sich zu differenzieren und für den Kunden einen Weg strategischer und kundenorientierter an den Markt zu kommen. Für Unternehmen und Agenturen die starke und tief gewachsene Hierarchien leben ist Scrum allerdings schwer, da man sich von dem klassischen Prozessen lösen muss.