Lean UX: Getting Out Of The Deliverables Business

Veröffentlicht: März 7, 2011 in About Webdesign, Programming, Webdesign

User experience design for the Web (and its siblings, interaction design, UI design, et al) has traditionally been a deliverables-based practice. Wireframes, site maps, flow diagrams, content inventories, taxonomies, mockups and the ever-sacred specifications document (aka “The Spec”) helped define the practice in its infancy. These deliverables crystallized the value that the UX discipline brought to an organization.

Over time, though, this deliverables-heavy process has put UX designers in the deliverables business — measured and compensated for the depth and breadth of their deliverables instead of the quality and success of the experiences they design. Designers have become documentation subject matter experts, known for the quality of the documents they create instead of the end-state experiences being designed and developed.

When combined with serial waterfall development methodologies, these design deliverables end up consuming an enormous amount of time and creating a tremendous amount of waste. Waste is defined as anything that is ultimately not used in the development of the working product.

Ux-discussion in Lean UX: Getting Out Of The Deliverables Business
Engaging in long drawn-out design cycles risks paralysis by internal indecision as well as missed windows of market opportunity. Image by opensourceway.

As organizations struggle to stay nimble in the face of an ever-changing marketplace that is disrupted constantly by incumbents as well as start-ups, getting to market fast becomes top priority. Engaging in long drawn-out design cycles risks paralysis by internal indecision as well as missed windows of market opportunity. In other words, by the time the company decides internally how the product should be designed, the needs of the marketplace have changed.

Waterfall software development looks something like this:

Define → Design → Develop → Test → Deploy

The design phase typically breaks down like this:

Wait for requirements definition to take place and get approved →
Consume requirements documents →
Develop high-level site maps and workflows →
Gain consensus and approval →
Develop screen-level wireframes for each section of the experience →
Present to stakeholders and gain consensus and approval →
Create visual designs for each wireframe →
Present to stakeholders and gain approval (after repeated cycles of review) →
Write The Spec, detailing every pixel and interaction →
Usability test for future improvements →
Hand off to development for review, approval and start of implementation

This phase can take anywhere from one to six months depending on the scope of the project, leaving many wasted hours and much designer frustration in its wake.

Read the whole article on www.smashingmagazine.com

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s