Is Your Organization Ready for Digital Prototyping?
Five Essential Elements to Get Started
Business, you might have read, is in the throes of a major digital transformation. Well, some companies have transformed, or are in the process, but nearly all organizations understand that digital must play a significant role in their business. “Adapting to increasingly digital market environments and taking advantage of digital technologies to improve operations are important goals for nearly every contemporary business,” writes MIT Sloan Management Review in their “Achieving Digital Maturity” report. “Yet, few companies appear to be making the fundamental changes their leaders believe are necessary to achieve these goals.”
Many firms try to create new digital services using human-centered design, relying on the learn-build-test-repeat methodology. This requires them to hone their ideas until they’re mature enough for scaling. Unfortunately, our experience shows that companies trying to build digital processes for digital service design often underestimate the importance of building a sandbox (an isolated experimental testing environment) to test and iterate digital offerings before scaling them.
As your organization bravely goes digital, it’s important to take into account certain technical and organizational requirements. Experience has shown us that there are five essential organizational elements to consider before building a technology sandbox:
1. Build an Adaptive Governance Model
The team testing and building a new digital service must be empowered to make decisions without having to wait for permissions or fill out piles of paperwork. This group needs, from the start, sufficient autonomy and freedom. This might mean that they’re allowed to procure new tools or technology without lengthy organizational processes. Or if there’s a need to iterate quickly, they can modify their infrastructure to make it easy to experiment while maintaining strict standards. It’s also important to have a cross-functional team with representation from technical functions to guide the team as they work on building the sandbox.
This does not mean that the team is solely reliant on self-governance; it’s all about adapting the governance model. This might mean that leadership participates in the project, visits the teams, learns about their progress in a more casual, collaborative format than at structured quarterly meetings. It’s also valuable to establish guardrails for the team’s decision-making. For instance, you might want to establish monetary limits before the team needs to get outside approval.
2. Understand Your Prototype’s Purpose
The point of a learn-build-test-repeat approach is to learn as you go, so that you’re able to course-correct earlier in the process (when changes are much faster and cheaper), rather than at the end (only to find you’ve veered far off course). Your ability to course-correct depends on how quickly you learn, and the quality of this education. Testing a prototype is how you learn, which means that your choice of prototype is crucial.
A prototype is anything that represents your idea, in a tangible format, to actual customers for the purpose of gathering feedback. It is a testable hypothesis about value or technical feasibility. A good prototype minimizes the time and cost needed to get smart about a new offering. Early on, when you’ve identified some key ideas and need to understand which ones are worth pursuing, storyboards or paper mock-ups are appropriate. As you continue, you’ll want to know how a selected idea is best translated into a design. At this point wireframes, high-fidelity mock-ups, or a non-production implementation of a key interaction are ideal. Finally, to observe users interacting with your design and assess real demand, a minimum viable product (MVP), which customers can interact with in real-time, may be the right choice.
3. Define Learning Goals
Learning goals are key questions to be answered in order to improve an idea until it’s strong enough to enter the marketplace. These can range from understanding the validity of a concept to specific functionality within a service. Do customers value the service? Will they want to use it? Is an app the right method for delivering the service? Will people want the information in multiple tabs or a single scroll down page?
In our experience, there are two levels of testing required to gather robust feedback.
Guided testing. This is an organized, orchestrated version of testing, in which the environment as well as participants are carefully selected to mimic the real world. Guided testing is often the exclusive form of testing for early and mid-stage prototypes, and can continue to be valuable even in later stages. A small number of participants—six to twelve—are asked to engage with the prototype in guided ways and describe what they are thinking. This dialog helps us to get a better understanding of how they do, or don’t, value the idea or embodiment of the digital service.
Unguided testing. This is the in-the-wild version of testing, often used with late-stage prototypes. A large number of participants are given access to the digital service, but no prompts are provided as participants interact with the service. The experience should be authentic, but the behind-the-scenes implementation providing that experience need not be real. For example, team members can operate customer service lines or manually process and fulfill product or service orders. Selected participants will get an opportunity to provide feedback.
4. Test at the Right Scale (Level of Investment/Fidelity)
Selecting the right type of prototype for your project depends on your stage in the process and your learning goals.
Organizations often feel the need to write software to test digital prototypes, but that can be a mistake. Many early and mid-stage prototypes can be built very quickly using tools like hyperlinked PDFs, InVision, or Balsamiq. If you need to test a complex or involved interaction, you will run into the limits of these tools, and need to move to a real front-end implementation (e.g., HTML, CSS, and Javascript for a website or web application). But you probably don’t need a real back-end implementation unless you truly need persistence across sessions for your prototype. A single page app, such as one written with AngularJS, can serve most mid-stage needs, saving significant time by avoiding having to create a real back-end.
What matters is that you have an experience that looks and feels like the real thing—but it doesn’t have to work like one.
5. Define Criteria for Selecting Prototyping Tools
The right tools will allow you to quickly build prototypes without needing lots of time or expertise. All these tools have some advantages and disadvantages. But before getting into selecting the tools, you must define the selection criteria to make an informed decision.
• Current organizational tool landscape. What tools are your organization already using that are appropriate for different prototypes? Is there a possibility to re-use some of them? For example, if your organization’s developers are using the LAMP stack (Linux, Apache, MySQL, PHP), don’t switch to the MEAN stack (MongoDB, Express.js, Angular.js, Node.js) as your default for MVPs and new releases, even if you decide that it’s a better tool in the long-term. This helps to create a gradual change in organization instead of a radical change and helps in adoption of the learn-build-test-repeat model. What types of prototypes does your organization not have tools for? A full development (e.g., LAMP) stack would be a bad choice if all you need for a prototype is a wireframe. Discover your gaps, and find new tools to fill them.
• Data requirement. Will your prototype use real user data? Will it be pulled from your current database? Will the input from your users be stored in your databases?
• Security requirements. The data requirements lead to security questions: Who should have access to your prototype? Will users need to create an account? Who will be able to make changes to the prototype? Are there privacy or security provisions that must be in place for new information you collect? Is there an established way to access actual customer data in an unfinished product, while maintaining your organization’s standards? Are your development and legal teams equipped to make decisions on where strict processes and oversight is necessary, and where it can be significantly relaxed?
• Long-term use. Most of the time, prototypes are testing beds, and whatever gets built as part of the testing prototypes is discarded. But that need not be the case, if you want to use elements of the design or codebase of your prototypes in your actual product. Especially in later stages, choose tools that will help in the transfer.
Based on your stage of the process and prototype needs, consider these criteria in deciding which tool to use in building your prototypes. There are always tradeoffs involved in these decisions, so it’s always valuable to have all necessary information before you make any decisions.
The Strategic Sandbox
Building prototypes and cultivating innovation is different from everyday work. It’s all about building a different governance model, developing learning goals, and adapting your standard processes. Hence, to be successful, it’s crucial that your innovations are separated from daily organizational operations and nurtured carefully. Remember to be patient, smart, and strategic at every step of the process. Happy prototyping!
