Last updated in October 2024.

Envivo has provided software consultancy for many projects over the years, across various different domains. In each project we needed to figure out:

a) What the Client’s problem is
b) How software can offer a solution

Which means getting into lengthy conversations to tease out key information. Sometimes the things that we hear are vague or ambiguous, so we need to establish the facts within every statement.

Here are the main 3 hills to climb:

1) Making sure we’re solving the right problem

Clients can have a hard time imagining solutions. It’s not their job: they describe the problem, and they hire us to imagine and provide the solutions.

They prefer to see visualisations, to understand how the software will solve their problem. On numerous occasions we’ve been asked “build something, then we’ll tell you if it’s right” (a common pattern seen by development teams around the world).

So the industry standard response is to create visual mock-ups or prototypes. Creating these can be time-consuming, but knowing what to build reduces the risk before the Development phase starts.

Visual mock-ups are typically quicker to create than prototypes. However:

• They require a UX person, with the relevant tools and skills (many Developers will admit to lacking these skills)
• Mock-ups are usually static. If a software feature has several inter-related steps, each step needs to be mocked up.

The biggest problem with mock-ups is that Clients focus on optimising their processes. They want less information clutter, and speedy UI interactions. This has a serious side effect: it inadvertently removes the transparency of what happens behind the scenes.

Prototypes are the alternative to visual mock-ups. Prototypes are more complicated, as both UX and Development expertise are needed. However, they are much better at demonstrating how a software feature might flow, but early prototypes won’t have enough fidelity to expose nuances.

In our experience, those nuances are where fundamental domain knowledge is hidden. In the discovery phase of any project, domain knowledge is more important than workflow optimisation.

2) Information accuracy and fidelity

We’ve also found that Clients have difficulty in articulating their needs in a structured format. Key domain knowledge is often obscured within conversations. If we don’t capture enough information, we may miss something fundamental.

For complicated domains, the effort of translating business requirements into artefacts for the Development teams can be huge (and lengthy). And getting too bogged down in the details can lead to Big Up Front Design – and we’re not here to fall back into the “waterfall” age!

3) Feedback cycles and momentum

Reviewing the mock-ups with the Client leads to further discussions, which lead to further changes. New ideas are born, existing ideas are updated, and some ideas are discarded altogether.

Mock-ups need to be revised to show these changes, and ideally they should happen at the same pace as the previous work. But making alterations is still an expensive process. Changes to an idea might require re-building a mock-up from scratch. If we don’t keep the momentum going, the Development team suffers from information decay.

DOMAIN EXPLORATION AND DISCOVERY IS REALLY HARD!

This cycle repeats for every feature, and the discovery process can become lengthy (and sometimes frustrating) for both parties… until all parties have a common understanding of both the problem and the proposed solution.

Fresnel: A New Way To Explore and Share

Fresnel was born from a need to tackle these pain points.

1) Concepts and ideas are captured directly into code

Drawing on a whiteboard is fun, but the real work happens in code. Coding needs to be minimal, and fast. We only to describe the structure and interactions within the model, with apply a sprinkling of configuration to bring the prototype to life.

We use the code compiler to tell us what’s broken. If an idea or concept doesn’t work in code, then the idea is incomplete (or wrong). That’s the cue to go back to the Client to get more clarification.

2) Visualisations are automatically generated

Let’s face it: most business software has the same UI features:

• Fields to show and edit data
• Organising fields into sections
• Tooltips to guide users
• The ability to create and save records
• Searching capabilities

Fresnel provides these for free. Which allows us to steer the focus towards the domain model, instead of the UI. If people ask about changes to the UI, we ask “Why? What’s the reason?“. Those conversations often lead to additional information hidden in the domain.

3) More transparency, less translation

By removing focus from technical infrastructure code, we can stay focused on designing the domain model that fits the problem space.

These models use the same terms that are captured from conversations during the analysis phase. We use this glossary of terms to name and document elements in the code, and let Fresnel display them automatically in the UI.

In conclusion

Our Fresnel prototypes are like “WYSIWYG for business applications” – but turbocharged.

Unlike the typical development process, we don’t want complexity to be hidden – we want teams to collaboratively explore and expose it.

We can demonstrate these findings with our Clients, and be confident that the team is building the right solution.