Shaping a solution is not an easy task. There are so many dimensions to take into account, that one who would like to address them all at once is doomed to fail. Starting from the videogame analogy, we crafted our own domain specific ubiquitous language. By standardizing and structuring the way we are thinking about and designing solution, team can allocate bandwidth to focus on other concerns, such as how to deploy solution, aka the space dimension. That’s for the theory. Let’s see how it pass the practice exam.

Modus Operandi

Prior to engage it’s important to agree upon how we will proceed. Now we have defined our ubiquitous language, one may notice we need at least two profiles, namely a functional profile and a technical one, to address the different topics. We are used to talk about Product Owner and Architect to name those profiles.

Ideally, you should have one or both positions covered within the team (“acting as” is better than nothing). If you don’t, you are in trouble. Period. Assuming your team is properly structured, we can split activities between those profiles:

• Product Owner will handle the stage/section/objective split, as well as the rules definition
• Architect will deal with skills allocation and tooling requirements

It is neither sequential work nor one-shot activity. Product Owner and Architect are continuously refining their proposal, nourishing each other and thus enriching solution. Nothing new there, but plain old Agile mantra.

Storyboard

Storyboarding activity is not new. It’s broadly used (movie, comics strips, …), in fact everywhere we have a sizable story to tell, and we would like to gauge outcome prior to engage. Guess what, it’s also what solution is all about. This said, boarding end-user in a guided and pleasant journey involves some preparation. Luckily, as we defined the method, we only have a recipe to unfold.

Below materials were shaped in an early design stage of a brand-new solution to showcase how method applies.

Synthetize

Above materials come with two issues, namely verbosity and ui/ux coupling. In other words, leveraging interface wireframe to land our pieces both burdens outcome and impinges UX designer realm. As we stressed in previous post that semantic split should not affect UI layout, we should prefer this more concise and agnostic way of surfacing information:

One may have noticed we reuse the pattern we are used to to provide context while making explicit what we are focusing at. We also materialize legend to gently support newcomers. Remember, you audience is heterogenous.

Streamline

So, we apply method to a single solution. Well done but how to ensure method can be standardized as we claimed for. There is but one way. Exercise method on another solution. Below material originates from another solution.

You may notice here:

• How all sections and objectives but also skills and rules are gathered for a specific stage on a single picture.
• How context is smartly enriched with 2 dimensions, using hollow gray to anchor elements while leveraging dotted boundary to enrich with release forecast.

Zoom out

There is one well-known way of surfacing complex workflow, especially when it involves multiple lanes or users, the metro one. It’s interesting to see how humans standardize this visualization, streamlining UX wherever the metro lands. Our solution could benefit from such visualization as well, surfacing a condensed view of the underlying complexity. Obviously, usefulness of such view will increase as soon as solution introduces multiple personas or forks.

Track progress

Remember, when we introduced videogame analogy, we noticed that taxonomy could also be used to track progress. Within a workflow ecosystem, tracking is always considered as a first-class citizen. We can of course map progress on the metro visualization we introduced just before, materializing, for both end-user and developer, where we are and what we achieved. Now imagine how beneficial it could be to have such information within every bug ticket.

Ability to chain stages, handle connections, book resources and recover from failures echoes another well-known ecosystem, the travel one. We should probably look at how they deal with such concerns. At the end, solution flow is but a user journey.

Closing

Defining our ubiquitous language structures the way we are thinking about and designing solution. Using a shared method for multiples solutions improves our ability to compare solutions but also to identify components - stage, section, objective, rule, skill - that look alike and thus will support technology reuse initiative.

Leveraging this brand-new language to model our solution allows us as well to shape and prompt audience with different display flavors. This is neither an easy nor a pointless task but remember that project success rate drastically increases according to the way you efficiently and effectively communicate, both internally and externally.