Embrace Rapid Prototyping with Salesforce

Early and continuous feedback from both users and stakeholders is critical to any software project’s success. Take some examples: through early feedback, this piece of software could potentially have avoided what I imagine must have been post-release user riots. I can also imagine users facing a medical emergency (or at least a change of pants) after seeing this popup around midnight which could also have been prevented through early feedback.

Beyond user experience horrors, early feedback can also course-correct incorrect requirements well before they are fully translated into wasted electrical signals.

Rapid prototyping

Prototyping is a powerful early-feedback tool no matter what technology you work with. Research shows that software meets user needs better if a prototyping is used as a technique, and if you have experience with it you probably don’t need research to tell you that. Getting it right, however, has always required a good deal of skill and discipline along with the right tools …

… But as we will see, Salesforce makes rapid prototyping very, very easy.

Idea to functioning app: hours, not days

A fully functional app within hours instead of the traditional weeks is the point of low-code platforms like Salesforce. In fact, a functional app within hours is how almost every Salesforce project starts. You put together a data model, create an app, configure page layouts and start working from that shell of an application.

This presents a tremendous opportunity. Instead of lengthy requirement gathering and design activities before development starts, we can put a fully functional application (or well, at least a barely functional application) in front of users and stakeholders as soon as we have a basic idea of what the data model should be. Put that basic app out there, present to users and stakeholders and gather feedback. Rinse and repeat.

Evolutionary and Throwaway Prototyping

Prototyping has consistently been shown to be effective but it does come with risks — one of the biggest risks being the prototype evolving into a full application with enough technical debt to warrant an immediate bankruptcy. A less risky approach is to use “throwaway” prototyping which mandates that you throw away your hacky prototype once it’s clear what needs to be built, and then start from scratch for the less-hacky production system.

Evolutionary prototyping is where Salesforce shines. For starters, you begin by developing and refining the key entities and their relationships, which ensures your early iterations weed out potential issues with the data model giving you solid base to build on. As you refine the foundation, the technical debt you incur is far easier to clear out because you’re still dealing mostly with declarative elements — which means manageable metadata, not spaghetti code. By the time you have a clear enough vision of the end goal, the odds are that you have a solid base to build on.

That said, all circumstances are unique, and you may find yourself mired in levels of uncertainty that do warrant a throwaway prototype. Managed properly, the Salesforce metadata-driven model is resistant but not immune to technical debt and your prototype may still need a good amount of code.

Top-down and bottom-up

In the software development world, we tend to do design what we intend to build before we build it. We may still do some sort of prototyping like wireframes, interactive mockups or even use a specialized approach to prototyping like quick and dirty JavaScript apps, but the ultimate goal is to know what you’re building before you build it.

This top-down approach is not a bad thing at all. The last time an empty head on a sharp suit asked you to build something but nobody knew what that something was probably didn’t leave you with positive memories.

With Salesforce, however, things turn out very different when you design too much first because Salesforce is very opinionated about what your solution should look like.

This trait is not unique to Salesforce. The majority of RAD or low-code tools I have come across are very opinionated on what the solution should look like, but developers approaching the tool with a top-down mindset often end up “fighting” the tool when it fails to enable their preconceived designs.

What works better instead is that you first understand the business problem that needs to be solved, start by building a basic app/prototype that would solve part or all of the business problem, and rapidly iterate to evolve it into a functional solution.

Embracing Rapid Prototyping

It’s easier said than done. The industry often does a fantastic job of replacing any interaction between developers and users/stakeholders with several layers of experts skilled in the art of missing the point. You not only have to embrace the practice yourself, but you also have to sell the idea to users, fellow techies and everyone in between.

Prototypes themselves face little resistance. Users and stakeholders love seeing something visual. The harder thing to sell is the fact that a bottom-up approach means Salesforce makes a lot of decisions on what the solution should look like — and this one usually comes down to the person with the checkbook understanding that it saves them a ton of money.

Regardless of the unique circumstances, however, there should be a good amount of benefit you could gain by embracing a bottom-up rapid prototyping approach to building applications on the Salesforce platform.