Our government clients always ask and look for technical innovation. However, more often than not, they are actually looking for "novelty" - something new that has already been invented by someone else but is still early on the Rogers' diffusion of innovations curve.
Some may argue, but to me,
True "innovation" is a verb.
It is the process through which something new gets created. It is the action of someone trying something categorically new in a problem domain that is barely defined and the resulting outcomes are unknown.
Sometimes, innovation is planned, systemic, or deliberate - like Eddison making 1,000 attempts before inventing the lightbulb. However, innovations can also be unintended, or even accidental. The X-ray, the microwave, saccharin, penicillin, the slinky, silly putty were all discovered by accident. It took prepared minds to follow through and turn that discovery into something useful, but the point is - what was found wasn't what was being looked for in the first place.
Sometimes, innovation lies in the trivial things and old concepts or tools, used or combined together in an unexpected way. Like, when a school teacher gave her class a mushy compound originally intended to clean coal sooth from wallpaper, and the kids loved it ( - the Play-Doh was born), or that Chinese cook who mixed together charcoal, sulfur, and saltpeter - common ingredients with very trivial use - and he got fireworks in his kitchen (quite literally).
Our example of unexpected innovation, doesn't come even close in significance and impact as the examples above, but it came very handy to a DevOps team working on a small minimum viable product (MVP) with a compressed timeline, and under significant pressure.
Meet the Wireframe-UI_Flow-Activity_Diagram-Detailed_Design Whiteboard Monster!
UGH! This sounds and looks too hairy and confusing! Maybe we should start from the beginning.
In the beginning, there was... a problem statement for a misleadingly simple MVP for a web-based application. The team used Agile Product Definition techniques to break down the problem statement into a backlog of user stories. One of the early artifacts that emerged during the conversations was the whiteboard site map and screen wireframes. It looked like this:
As a next step, the UI/UX team digitized the hand-sketches into high-fidelity wireframes and a clickable prototype.
Whiteboarded wireframes and clickable prototypes are fairly standard techniques used in web UI development. However, they have certain limitations, which we quickly encountered.
In our MVP, the user workflow was conditional based on user choices made on a couple of the screens, leading to multiple alternate happy-paths (not even counting the exception paths for handling user or system errors). The prototype, being non-functional couldn't emulate easily all different paths and illustrate the complex data-driven conditional workflow. The user story acceptance criteria were elaborate and functionally complete, but difficult to read and follow through all the IF-THEN-ELSE clauses.
In such situations, a good old Activity Diagram would do the job, but it has its own limitations too. What we gain in terms of visualizing the decision tree and the forks in the logic, we lose in terms of visualization of the UI screens and data elements.
Our solution? - improvise a really large "activity diagram" by Scotch-taping to the whiteboard each screen from the wireframe prototype and using a marker to connect the screens with lines to illustrate the screen transitions. The forks in the logic were drawn as the classic diamonds with "IF" questions and "Yes/No" branches. Thus, in a single highly visible artifact we combined the Wireframes, the UI Flow, and the end-user Activity Diagram. It looked like this:
You may notice that we also took the opportunity to map each screen to the user story that implements it. We scribbled some questions and clarifications right next to some of the pages, and in a couple of instances, we put comments next to the page elements that had conditional behavior.
Posting this on the whiteboard caused a spontaneous team huddle up and a walkthrough. During the walkthrough, many new questions were uncovered and we made further scribbles and touch-ups to the screens. Most importantly, seeing the MVP at a glance for the first time, caused the domain expert to revisit and fine-tune some of their original requirements, which had a trickle-down effect on the user stories, the screens, and the workflow logic - not big enough to be pushed back to another sprint, but significant enough to cause a couple-day worth of rework should have we implemented first and demoed the fully working UI.
The updated Wireframe-UI_Flow-Activity_Diagram map looked like this:
You may notice the flow changed a little with not one, but two condition checks, and corresponding specs underneath for the data fields and possible values. Additional notes emerged on the Post-its. The UI team wrote on top of each page the respective URLs so that the rest of the team knew how to reference and test the pages. As the UI team kept refining their screens, they printed and replaced each page a few times. (You may notice the stacked pages in a couple of places.) Since the team was co-located, this provided an instantaneous "notification" of the change and a single source of reference.
Soon, this part of the whiteboard became like the watering hole in the savannah - team members swarming, discussing, negotiating API interfaces, troubleshooting unexpected behavior, clarifying questions, referencing specs.
The map took a life of its own growing organically and more details emerging. You may notice a few endpoint names were added, a few additional screens too, and even a note that two of the night-owl developers left for the UI team to read in the morning. Hence, the full name: Wireframe-UI_Flow-Activity_Diagram-Detailed_Design Map. It is a chockful :) and I'd rather call it - the FlowMap.
The FlowMap is by no means a substitute for proper documentation. Everything meaningful was eventually documented in Jira User Stories, Confluence wikis, REST Docs, and in the BDD test cases. Yet, none of these long-living artifacts came even close to showing in a single pane of glass a fully integrated picture of virtually all design details needed to quickly and correctly build the MVP.
Nothing in this method is new, or shiny, or earthshattering, and certainly, it does not look pretty! Yet, we have never seen it used before in this form. It cost the team a negligible amount of time to put the FlowMap together, but the impact and usefulness of it saved days worth of miscommunication and rework. The method can be used on any project (MVP and post-MVP) with complicated multi-step end-user workflows with complex behind-the-scene logic. Potentially, it can be extended to other use cases as well.
The idea is free, but I'd love to hear back where you have used it and how!
Comments