Building the right software – and for everyone.

It has been almost a year into the project. The client was uneasy. We had consumed significant and costly months on exciting participatory design sessions. Several sprints had passed, and we had a working MVP by then. This was truly innovative software. By the way, we had been hired precisely for that: to build innovative software.

We alerted the client about the importance of early testing with the final user. We’ve been using prototyping software all along, a very famous one. Our open-minded client was convinced of the importance of the strategy but insisted on waiting for a working product, an MVP. High fidelity prototype was not high enough for them. They’ve selected the group of potential users and wanted the trials to be perfect. So, no room for improvisation. They saw prototyping as just that: improvisation. They were perfectionists. How could we, advocates of superior user experience, blame them?

Startups are bets. Will future customers entertain the same enthusiasm of the entrepreneurs financing the project? How will the features so treasured, so polished during product construction, be perceived? Software features, especially in startups, are hypotheses. Sponsors are betting that the functionalities they chose will enchant their future clients. Many excellent texts were written on the need for early testing. Early testing reduces risks. A lot. The survival rate among startups is very, very low. They should care more about early testing.

The issue is why hot money sponsors are reluctant to adopt early testing. The answers come with little effort, as they orbit around the same old factors: time and money.  Testing requires time and money. That will postpone the product's debut, even if the product is not the right one. And, as we’ve learned, risk. Risk of exposing your baby too early. And exposing it to influential people, as our client saw.  Entrepreneurs hate anything that can cause delays in schedules and hurt budgets. Educating them is not enough. We need better tools.

If our prototypes could deliver an experience closer to the actual final product, maybe the client would have agreed to use them in early testing.  Our prototypes were as high fidelity as the prototyping tool (one of the best in the market) would allow. Not enough. The experience is still far from the final product. Our client was right; we had to wait until we had working software.

It’s long been observed the gap between design and development. It’s as if they are from different planets. They study different subject matters and attend distinct undergraduate courses. They love what they do and respect the work of each other, but they still seem to be from different worlds.  The boundaries are clear. To cross them, there is even a term, like if you need to clear customs to enter another country: the handover.

Prototyping software seems to corroborate and solidify that gap. Leading software companies help designers easily build beautiful prototypes. Our client prototypes were especially gorgeous – they care much about this aspect. However, the handover is no more than guidelines (usually poorly specified). Developers still have a lot of work ahead to implement that trail (like an open trail in the woods). When one looks closely into the design document (internal structure of a Figma / adobe prototype), one cannot recognize primitive widgets, like text fields, labels, etc. There are third-party code generator plugins. They scan the design document and generate HTML code. The quality of that code is debatable. Professional developers despise that code. And that’s understandable. Code generation has always been a challenge. But this is out of the scope of this discussion.

To bridge the gap, we decided to invest in a gallery of micro frontends (MFEs). They are live components, working software that can be reused in new applications. The approach has the advantage of being discoverable and inserted into the prototype during participatory design sessions. The plugin also generates code that can be used in early testing. Important to notice that the code is just partially generated since parts of it are already built and deployed into production, good code. Coders and designers collaborate to adjust our code generator to produce the best code possible. They are talking…These tools are available to our clients who get to use both the micro frontends and the Figma plugin.

Those MFEs are accessible for people with seeing and hearing disabilities. MFEs have a life cycle of their own so that future versions will accommodate other disabilities. If we are in the business of building quality software, it has to be accessible. 

By the way, to wrap up that client story, we did perform usability tests with real clients once we had the software. And they perceived things differently from what was expected. And we were able to adjust the software before the product launch.