Getting out of the deliverables business

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

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

Meanwhile, based on that User interface specification, a visual designer, individually, made stunning pixel-perfect visual designs for each and every screen of the application. Given the functional specification, a technical analyst created a technical specification and application design trying to capture all the given information, in a deliverable that would make sense as input for development. Sometime later, a copywriter was given the assignment to write on-screen text labels and copy, based on the wireframes. And even some times 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 rose about the User Interface of the application and a usability engineer reviewed the User Interface specification to give some advices 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.

Silo teams

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 outcome. 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). Output of one phase, is the input of the next phase. Lack of common understanding (not by the fault of the individuals), each individual needs to re-interpreter the work of the previous. No real sense of ownership.

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

Assumptions, lots of assumptions! Hypotheses based on those assumptions. A requirement spoken by the guy from marketing – as great as it might be – remains an assumption until proven by the market: feedback from real 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 it weakest link.

Teams used to a sequential process have become accustomed to handoffs between specialists. Each team passes off their work to the next team. Each of these handoffs includes overhead in the form of meetings, documents to review and approve, waiting time, etc. Anything which does not directly contribute to the goal of the project: creating software – is waste.

Let’s reconsider.

Once upon a time, there was a marketing guy, with a great idea for a new software application.

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

The team focused on the outcomes that would address the main customer need of our application. In a lightweight manner, the idea was conceptualized: the team formulated some hypotheses: valuable features that they considered as 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 together the UI sketches to an “interactive” prototype for internal validation. Taking into account the received feedback, the team refined that small set of features to the level of user story with the main acceptance criteria.

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

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 real back-end data.

Over the course of time, the team improved the product with feedback of customers, they included new insights, they dropped a few – previously considered “must-have” – features, and they integrated a new online service that appeared to be a good fit to 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 are 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 prioritized. There’s no all-inclusive upfront analysis, there’s no big design application design up-front. There’s no detailed product functionality roadmap. The design emerges or rather there’s a sufficient design up front.

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 organized 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.

Lean UX

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 documented 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 in an iterative and incremental way.

Yes, there are exciting times ahead!

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

Comments are closed.