Once upon a time, there was a marketing person with great ideas for a new software application.

He hired a business analyst, who described all those ideas in formal specifications fully documented business requirements (including use-cases, business rules, exceptions …). This deliverable was handed over to a User Interface / User Experience expert who created a detailed User Interface (including wireframes, site maps, screen flows, mock-ups,…) and described all the user interactions. Next, a functional analyst translated those requirements to an available specification and tried to figure out how to connect them to existing infrastructure and systems.

Given the functional specification, a technical analyst created a technical specification and application design to capture all the given information in a deliverable that would make sense as input for development. Meanwhile, based on that User interface specification, a visual designer, individually, made stunning pixel-perfect graphic designs for every screen of the application. A copywriter was sometimes assigned to write on-screen text labels and copy based on the wireframes. And even sometime later, a tester was given the assignment to understand the requirements and write test scenarios.

Development was about to get started!

Sometime later, during development, some concerns arose about the application’s User Interface, and a usability engineer reviewed the User Interface specification to give some advice and remarks.

So, what do we observe?

• The work goes sequential
• Individuals doing their own thing, producing output: deliverables, documents!
• Time passes by
• Handoffs, with potential gaps for misunderstandings, misalignments, information lost in translation

Let’s retrospect.

The goal was to create a new software application – with probably a fantastic idea in my mind and initiated by a great business case. Where is our software?

Focus on outputs, not outcomes. People are appreciated for their output: mainly documents and the quality of those documents.

Those documents are written by an individual or a group of individuals of the same expertise – documents are passed on (with or without explanation). The output of one phase is the input of the next phase. Lack of common understanding (not by the fault of the individuals), each needs to re-interpret the previous work—no real sense of ownership.

It’s a very time-consuming process. From inception to the actual start of development, it can take months – depending upon the size of the project.

Assumptions, lots of assumptions! Hypotheses based on those assumptions. As great as it might be, a requirement spoken by the guy from marketing remains an assumption until proven by the market: feedback from actual end-users: the customer.

There is little to no opportunity to react and correct the design of the new software application when new insights or market conditions come up meanwhile developing.

Probably the whole process is overseen and controlled by a commanding officer.

Where’s our marketing person? Out of sight

A chain is only as strong as its weakest link.

Teams used to a sequential process have become accustomed to handoffs between specialists. Each group passes off their work to the next group. These handoffs include overhead in meetings, documents to review and approve, waiting time, etc. Anything that does not directly contribute to the project’s goal: creating software is waste.

Let’s reconsider.

Once upon a time, a marketing person had a great idea for a new software application.

The sponsor gathered a team with expertise in IA/UI/UX, usability, customer engagement, front-end/back-end development and testing. The team formulated the new application’s business goal and desired business outcome with the marketing guy. Together, the team made this set of skills, not an individual, for each required expertise.

The team focused on the outcomes that would address the primary customer need of our application. The idea was conceptualised lightweight: the team formulated some hypotheses: valuable features that they considered a good collection for a ‘minimum viable product’ and a set of metrics to verify those hypotheses. Next, the team draw some UI sketches on paper. The team set out a test by linking the UI sketches to an “interactive” prototype for internal validation. Considering the received feedback, the team refined that small set of features to a user story level with the main acceptance criteria.

The team decided to prototype directly in HTML/CSS as this was the preference of the web developers. The team organised a user test with key customers and external (non-customer) people. These tests and the earlier defined metrics concluded and prioritised several improvements. Collectively, the team came up with the adaptations. With minimum documentation effort (again: main wireframes and a list of agreed-upon decisions), They improved the prototype and discussed a subsequent set of functionality.

Meanwhile, the needed services were encoded and deployed to connect the front-end with the back-end system. The next test showed the application with actual back-end data.

Over time, the team improved the product with customer feedback. They included new insights, dropped a few – previously considered “must-have” – features, and integrated a new online service that appeared to be an excellent fit for the solution.

So, what do we observe?

The focus is on creating working software; that’s what we care for!

Documents do no solve user’s problems, working software does.

The focus is the outcomes; the focus is the vision. The team liberates itself of endless discussion regarding functional features. The attention is directed on user needs, and in that problem space, possible solutions (hypothesises) to address those user needs are presented and challenged.

Feature development is prioritised. There’s no all-inclusive upfront analysis, and there’s no big design application design up-front. There’s no detailed product functionality roadmap. The design emerges, or instead, there’s a good design upfront.

We eat the elephant in small chunks, but we prioritize the chunks.

The team organises itself to collaborate. Insights, proposals, experiences, expertise are collected, and in a healthy synergy, the team shares and co-creation happens – with the customer. The customer is central.

Instead of an open-loop system, the project is organised as a closed-loop system: actual feedback of end-users is incorporated iteration-by-iteration to evolve the application and its features. The “apply-inspect-adapt” cycle is a “probe-sense-adapt” approach. The team plans for experimentation, the team is ready to react when new insights arrive. There’s no anxiety about changes.

What about documentation? When required, additional application designs or an overview of architectural components is delivered. Besides that, the product (software) itself is the documentation. Visual elements are documented in the application itself. The developed front-end is the library of reusable components. The web services themselves are established and are self-explanatory in terms of logic.

Modern software development environments and software craftsmanship practices allow this kind of rapid application design, construction, testing and delivery iteratively and incrementally.

More info on Lean UX? Read the book by Jeff Gothelf.