Refining Design with Prototypes
One Prototype Is Worth a Thousand Meetings
Imagine an organization needing a highly interactive customer portal. A business analyst interviews stakeholders to clarify needs into well-understood requirements. Discovery goes well, defining terminology, process flows, and user stories for the portal.
The stakeholders later convene to sketch out screen layouts, where the business analyst struggles to show the portal’s look and feel. The stakeholders want a dynamic user experience, adapting to the customer’s input. The business analyst foresees sketching screens for many review meetings, consuming stakeholder time and energy to imagine and work out the solution’s behavior.
The business analyst and architect decide to build a prototype, a small part of the solution that only demonstrates the user experience. Once the stakeholders see the demonstration, they have a clearer view of possible interactions and constraints, such as how much they can fit on a page. It also gives the business analyst and architect additional insight into the stakeholders’ expectations.
They collect feedback from the demonstration, incorporate it into the prototype, then demonstrate it one more time. The second demo confirms the changes the stakeholders wanted for the portal. They get excited about the portal rollout and promote it internally. Management looks forward to offering it to customers. Finally, the business analyst and architect conclude the prototype saved them enough meetings to make building it worthwhile.
Prototype Purposes
In their book Software Requirements, Karl Wiegers and Joy Beatty define a prototype:
A software prototype is a partial, possible, or preliminary implementation of a proposed new product (solution). Prototypes can serve three major purposes, and that purpose must be made clear from the very beginning:
Clarify, complete, and validate requirements.
Explore design alternatives.
Create a subset that will grow into the ultimate product.
The added emphasis points out that business analysts and architects should first determine a prototype’s purpose before building one. For example, if it would improve requirements quality, the prototype should focus only on ambiguous or incomplete requirements. For design alternatives, it should only cover critical design areas.
The book also specifies two kinds of prototypes. A throwaway prototype works best for improving requirements quality and exploring design alternatives. Once it serves that purpose, the stakeholders discard it. Minimal effort goes into developing a throwaway prototype because of its short lifespan.
An evolutionary prototype is a bare-minimum solution intended to go into production. Agile development often starts with an evolutionary prototype designed for incremental changes. Then, the development team builds it to production-quality standards because the prototype will evolve into a finished solution. Therefore, creating an evolutionary prototype takes longer but throws nothing away.
Rapid Prototyping in Salesforce
Salesforce lends itself to rapid prototyping with its no-code platform. Business analysts can easily create objects with fields to contain data. Objects include forms to enter and change data. They can build simple reports as well. However, stakeholders usually need more from a prototype than maintaining records and running reports.
Business analysts and architects familiar with Lightning pages and Flow can use them to show solution behavior without writing code. For example, a prototype’s flow has these steps:
Select a task to perform
Enter data into an object based on the step 1 selection
Enter data into a related object based on input from step 2.
Each step displays a Lightning page, with the flow controlling which page appears next. Business analysts and architects create just enough objects, Lightning pages, and Flow to fulfill a throwaway prototype’s purpose.
Salesforce’s plethora of no-code development tools can tempt technical stakeholders to create an evolutionary prototype instead of a throwaway prototype. For example, a demonstration app initially meets basic requirements using Lightning pages and Flow, so it goes into production. As new requirements emerge, developers add Apex code to work around Flow's functional limitations. The data model is not well-defined, so the developers must rebuild the objects and their relationships. The stakeholders should have decided upfront to develop a quick and dirty throwaway prototype or take more time and effort to build an evolutionary prototype.
An evolutionary prototype on Salesforce requires a data model with well thought out names, labels, data types, and object relationships. A typical Salesforce solution has more dependencies on objects and their fields than anything else. So thoughtless evolution can cause unpleasant surprises when a “simple” object or field change breaks something else.
Putting the “Pro” in Prototypes
A prototype can improve requirements quality, show design alternatives, or start an agile development project. The stakeholders first agree on its purpose, then limit its scope to fulfilling that purpose. For instance, stakeholders want to see how a customer portal behaves when the customer enters invalid data in a particular context. A throwaway prototype has only that context built in, with just enough user experience to demonstrate the behavior.
A throwaway prototype should not have a finished look. Otherwise, stakeholders could experience the illusion of a solution, thinking they have a finished product because it looks that way. Also, business analysts and architects should resist temptation or pressure to “just” release an evolutionary prototype that’s not ready for production.
Business analysts and architects offer a prototype to save stakeholders’ time or give them a preview of one or two solution aspects. Once the stakeholders agree on the prototype’s purpose and minimal scope, business analysts and architects invest as little effort as possible on a throwaway prototype to reduce or even eliminate doubts about the requirements or design. Alternatively, if the technical stakeholders have enough time, they can carefully construct an evolutionary prototype.
Prototypes resolve doubts about a solution’s requirements or design while reducing stakeholder time and energy in review meetings.