Big Design Up Front

I am running into conversations around “designing upfront” quite regularly. This was the main reason why I decided to summarise one of my replies in this article.

The idea of defining Scenarios and UI Design upfront is great, but it can run into a few traps. These traps are not related to waterfall vs agile.

These traps are about design requirement’s form and content.

The more complex the product is, the more complex Scenarios, Use cases and Design framework are required. This often leads to over-sophisticated descriptions — a lot of wiki pages, walls of texts, tens of disconnected wireframes, sketches and diagrams, meetings.

Users and stakeholders have hard times to imagine how the product will feel like only from these disconnected artefacts, that changes rapidly over the time. Stakeholders are then not providing feedback to the product UX, but to these artefacts and isolated product areas.

This is resulting in these “eureka sessions” where the team gets first relevant users and stakeholders feedback only when the product increment is already implemented.

Stakeholders are not the ones to blame for this valuable feedback. Honestly, if you will give me a description of something that complex as BMW car, I would have hard times to imagine its driving experience, or answer questions like “On a scale of 1–5, please rank how easy is to park this car in your garage”.

Prototyping

The solution to this is to embrace prototyping as key and strategic activity. Establish prototyping as an ongoing activity, not as deliverable frozen in time.

Prototyping is the way how I am communicating with my team. I maintain click-through prototype, that represents real commitment. It is always up to date and it includes everything — interaction, content, visual design, planning. I don’t expect that stakeholders will read our docs and stories. But I am encouraging them to click through the prototype on their own — use the product, experience it. The same prototype is also our main artefact for user validation.

Documentation

If there is complex dropdown-inside-dropdown, drag-and-drop multi-slider never-seen-before interaction that launches nuclear weapons, it is not enough just to talk about it and describe it in any form. This pattern has to be prototyped before the team will build that nuclear weapon itself.

Form and Function

These are the moments where industrial design’s “form and function” meets together. During prototyping process of this interaction pattern, the team can realise that this is just too complex UI for any human to use. This is not coming from personas or any other formal technique, but from general Gestalt psychology and UI patterns heuristic evaluation.
The form can then influence the function. Perhaps the same user goal can be achieved with a simpler interaction pattern in a different layout that leads to a different feature. Maybe it is not even necessary to build that nuclear weapon at all.

But without prototyping, the form will never influence function. Teams are committing to something that looks good on paper. Specs are detailed, scenarios are there, use cases are crystal clear. But when they are implemented, it just does not feel right and does not “work as expected”.