Prototyping in Software Development

The problem

In our highly dynamic product and development environment, success is defined not just by building features but by building the right features the right way. Ensuring features truly meets user needs and are implemented in a long-term, sustainable way is a challenge.

Enter "prototyping," a tactic that can add significant value to the software development lifecycle by helping teams visualize and validate ideas long before the actual implementation begins.

Overall, the common goal of prototyping is to reduce unknowns, so we can make more informed, confident decisions during the early stages of a feature.

What is prototyping?

Prototyping refers to the process of creating a preliminary version or mockup of a feature or feature set, often in a format that's more visual and interactive than detailed specifications or diagrams.

The goal isn't to create a fully functional product, but rather a simulation that stakeholders can interact with, providing immediate insights into how the final product will look and function.

An equally important callout is that, unless explicitly requested, prototyping does not replace formal problem definition and UX solution development from PM and PD. It is meant to supplement those efforts, but a low-fidelity prototype should not aim to solve (or define) a user issues in the perfect way.

Prototypes can vary in fidelity:

Low-fidelity prototypes

These are rough sketches or wireframes, usually created without much detail. They are quick to produce and are useful for validating basic concepts and flows.

Typically, we will aim to produce a few low-fidelity prototypes to help UX decide on a direction to take their mocks. If the problem definition and solution design already feels confident, then low-fidelity prototypes can still be used to discover engineering unknowns early on. This can be helpful to set a better engineering design direction.

Low fidelity mocks will have tight timelines and are expected to be "throw-away" code. Any code that is shared for review should be only critiqued at the highest design level to flag possible dangers of approaches, and even then the review of code design should be explicitly requested.

Expectations and omissions:

• Realistic but "hacky" flow of a feature is produced and shared on a branch preview (or even just screenshots/looms)
• Code is not merged into master
• Code does not need translations keys, events, or error handling unless it is critical to uncover unknowns in those spaces
• Prototype is visually inconsistent where aesthetics don't detract from the goal of the prototype, and copy is done quickly and with little concern

High-fidelity prototypes

High-fidelity prototypes mimic the final product's look and feel closely, and provide demo-able progress toward the end result. These will often be used when direction is already set by product and UX, and we are fairly confident in the basic principles of the proposed solution.

High-fidelity prototypes are naturally a part of the standard project and should be viewed as the "WIP" to some degree. However, the goal is that these prototypes live in production behind a featureModule flag so that stakeholders can demo the work in progress without checking out a branch preview. This will equally encourage smaller PRs of in-progress work behind gates to allow others to more easily stay up to date on engineering decisions that are being made.

Expectations and omissions:

• A realistic flow that adheres fairly closely to the predefined course of action
• Code submitted should be safe to merge into master at regular intervals, even if the prototype itself is not user-ready.
• Code at this stage still can hard-code translations, omit events, and have unsafe error handling cases, but those instances should be less common and contained in nature (i.e., to a feature file)
• the prototype should be deployed at regular intervals in a state that is easily consumable for all parties, including external stakeholders that may get caught up in visual discrepancies. In this vein, it is often helpful to put in the extra effort to make the prototype more visually appealing and verify that copy aligns with large problem definition terminology. We still are looking for big picture feedback, so removing any nitpick-distractions can allow folks to more easily focus on the large concepts.

Think of HF prototypes as a stepping stone to the product code. It still doesn't need to be perfect at the early stages, but it should be readable, reviewable, and maintainable.

Why do we want to prototype? What does it result in?

Prototypes are inherently more engineering effort than simply building the feature after product and UX direction is set. However, I believe the benefits out-weight the cost.

• Rapid Feedback

  • For LFPs, we can quickly see how possible solutions will integrate with existing code, allowing for clearer solution design for UX. We may discover that certain user flows that we believed to be superior are actually less than ideal.
  • For HFP, we "broadcast" the state of development and allow for stakeholders to feel informed without the need for explicit status updates. We allow engineering peers to see the progress of design decisions, and allow UX/PM to request design changes mid-flight with minimal thrash

• Risk Reduction

  • For both types of prototyping, the goal is to uncover any unknowns as early on in the process as possible.
    • From the product and UX perspective, we can utilize those extremely early feedback cycles (pre-UX solution design) to more decisively commit to a solution.
    • From the engineering perspective, we can identify dependencies on other teams or stakeholders early in the process, so they can more easily prioritize their contribution to the feature.
      • Prototyping is also one of the most useful tools to improve estimation accuracy. Regardless of the need for a prototype from the product side of things, it's often extremely useful to spend 2 hours sketching out an end-to-end solution for a new feature to provide a better timeline.

• Stakeholder buy-in

  • Effectively communicating problem statements can be difficult. We utilize solution designs (i.e., UX mocks) to communicate the vision for a feature more easily and quickly to possible stakeholders, but mocks lack the interactivity that sometimes is necessary and can more fairly time intensive to produce at a level that gets buy-in.
  • LFPs, in my experience, are one of the most powerful tools to garner cross-team buy-in to a vision. A major concern is often technical feasibility, and proving that a prototype can be thrown together in a short amount of time can reduce concern over a bolder solution "taking too long"

• Development velocity

  • Above, I did say that prototypes result in extra effort, but I would argue that they don't result in extra work or longer development timelines. They can reduce the overall timeline through early unknown discovery, better team and stakeholder alignment, and better estimations (velocity is mentally calculated against an estimation, so even if the actual output is the same, if the estimation is more accurate, the velocity often can be perceived as being higher)
  • I also personally find that a super rough draft of a feature can accelerate the final code. If I sketch out 4 different approaches that solve a problem, I can ideally be more confident in the approach that I do chose, and share that information with others during review.

Conclusion

Anyway, I hope this rambling overview communicates my thoughts around the recent push for more prototyping. If this definition of prototyping feels off, let me know! The only goal here is to establish a shared understanding of what terminology we are using to avoid misalignments.

I personally am a big fan of this approach, but if prototyping truly doesn't seem to agree with your preferences, please let me know. This is just a tool in our collective toolbelt, and it is by no means a requirement. I would recommend folks try leaning into LFP development and sharing. We also will need to foster a productive space for others when they share LFPs, and avoid bogging down LFPs with unnecessary low-level scrutiny.