Building a Communication Platform – Learning Launch

Challenge  I help coordinate and manage a group of 80 nonprofits across the U.S. that support their local  communities by redistributing donated goods to other smaller nonprofits. My organization is the  national organization and the 80 nonprofits, called , are our  affiliate members. Each member has vastly a different mission and operating style: some are  food banks, some are churches, some are United Ways, and some are shelters. But they all have  crucial experience and wisdom to share with the others.     As the parent organization, our goal to help our 80 unique   feel like a unified community and help each other problem solve remotely. Communication and  maintaining a community feel across 31 states is our biggest barriers to success. When we host  our annual conference in the spring, we see collaboration and innovation happening naturally,  but it is quickly lost when the event ends. Our goal is to create a sense of community and ease of  communication that will last all year, so we invested in a popular intranet platform that would  require extensive customization.    We were starting with a blank state and open-ended possibilities of what features to build in for  our partners. Due to pressure to get started from above, we did not take a design thinking  approach from the start. We made basic assumptions of what features and designs would best  solve our communication challenge and we got to work. As we started to build features, I grew  worried about low levels of adoption from our 80 partners due to a lack of customer insight on  the front end.     Selection  We reached a point with our intranet where we could pause work in order to test our partner’s  reaction to the product. We were still at a phase in development where we could change  directions and plans based on feedback if needed without significant financial loss. We had  already completed beta testing on our basic features, which included an interactive map, a help  ticket system, a suggestions box, discussion forums, announcements page, and a dashboard of  historical knowledge. Our hypothesis was that we had created an intuitive platform for  collaboration and that the features would specifically address previous barriers to  communication. We needed to know, before going any further, that our customers would find  value in the solutions. We decided to conduct a learning launch to test our previous assumptions  about what features our partners would find most useful. A learning launch is a design thinking  tool to do just that; to test your hypothesis of how a user will interact with a product or how your  project or program will successfully function in the real world.    Application  We set up a learning launch in which 6 of our 80 partners from different states, missions,  backgrounds, and levels of experience with technology would be able to “test drive” the  platform. This was not a beta test, because we had already worked out the bugs. More so, we  wanted to test how our users would intuitively interact with the product and whether the features  matched their collaboration and communication needs. We did not want to sway or bias our

participants with our own enthusiasm for what we had created, so we chose not to have a face to  face video meeting in which we would explain the instructions.     Instead, we created a brief that explained what the platform was, our goals for creating it, and  where we were in the process. We emphasized that we were looking for all ideas and feedback  and that this process would be iterative. We created a video that introduced how each feature  worked as an orientation to the site. To capture feedback, we created a survey for each feature  with picture for orientation and a couple key questions as well as open ended responses. Then we  let our users into the platform to explore and interact. We gave our testers five days to explore  and record their reactions and reflections via survey. Then we analyzed survey data by  organizing anecdotal feedback and looking for patterns in their responses.    Insight  While we did receive confirming data about our overall goals, we also received crucial feedback  about confusion with some of the features as well as ways to add to features that we had not  thought of. We were able to meet with developers and quickly change our approach. We also  learned an important lesson for adoption: two out of the six testers did not follow the  instructions. That tells us that we should expect about 20-30% of users will not fully read or  understand our launch or onboarding instructions. We have since edited our full launch plan to  include multi-media methods to explain instructions.     The silver lining is that, although the two testers did not follow the proper instructions, we could  tell that they still used the platform as it was intended. This proved our ultimate goal that, while  users may not thoroughly read instructions, the platform itself is user-friendly enough not to  require extensive instructions in the first place.    Approach  While the learning launch was the best tool to use in at this specific stage for our challenge, in  retrospect we should have incorporated design thinking tools to our original challenge. We  should have incorporated our intended users in the process of defining the problem we were  trying to solve before we started working with developers. If we had started with the mind- mapping tool to help communicate on the same level and then incorporated visualization to  achieve our first prototype, we may have been able to launch a product without as many  “pivots”. Still, it was a valuable lesson to see that even if you do not start a project with design  thinking tools, you can still pause and use them to back track and test assumptions before it is too  late.


Building a Communication Platform – Learning Launch Challenge I help coordinate and manage a group of 80 nonprofits across the U.S. that support their local communities by redistributing donated goods to other smaller nonprofits . My organization is the national organization and the 80 nonprofits , called , are our affiliate members . Each member has vastly a different mission and operating style : some are food banks , some are churches , some are United Ways , and some are shelters . But they all have crucial experience and wisdom to share with the others . As the parent organization , our goal to help our 80 unique feel like a unified community and help each other problem solve remotely . Communication and maintaining a community feel across 31 states is our biggest barriers to success . When we host our annual conference in the spring , we see collaboration and innovation happening naturally , but it is quickly lost when the event ends . Our goal is to create a sense of community and ease of communication that will last all year , so we invested in a popular intranet platform that would require extensive customization . We were starting with a blank state and open - ended possibilities of what features to build in for our partners . Due to pressure to get started from above , we did not take a design thinking approach from the start . We made basic assumptions of what features and designs would best solve our communication challenge and we got to work . As we started to build features , I grew worried about low levels of adoption from our 80 partners due to a lack of customer insight on the front end . Selection We reached a point with our intranet where we could pause work in order to test our partner ’s reaction to the product . We were still at a phase in development where we could change directions and plans based on feedback if needed without significant financial loss . We had already completed beta testing on our basic features , which included an interactive map , a help ticket system , a suggestions box , discussion forums , announcements page , and a dashboard of historical knowledge . Our hypothesis was that we had created an intuitive platform for collaboration and that the features would specifically address previous barriers to communication . We needed to know , before going any further , that our customers would find value in the solutions . We decided to conduct a learning launch to test our previous assumptions about what features our partners would find most useful . A learning launch is a design thinking tool to do just that ; to test your hypothesis of how a user will interact with a product or how your project or program will successfully function in the real world . Application We set up a learning launch in which 6 of our 80 partners from different states , missions , backgrounds , and levels of experience with technology would be able to “ test drive ” the platform . This was not a beta test , because we had already worked out the bugs . More so , we wanted to test how our users would intuitively interact with the product and whether the features matched their collaboration and communication needs . We did not want to sway or bias our participants with our own enthusiasm for what we had created , so we chose not to have a face to face video meeting in which we would explain the instructions . Instead , we created a brief that explained what the platform was , our goals for creating it , and where we were in the process . We emphasized that we were looking for all ideas and feedback and that this process would be iterative . We created a video that introduced how each feature worked as an orientation to the site . To capture feedback , we created a survey for each feature with picture for orientation and a couple key questions as well as open ended responses . Then we let our users into the platform to explore and interact . We gave our testers five days to explore and record their reactions and reflections via survey . Then we analyzed survey data by organizing anecdotal feedback and looking for patterns in their responses . Insight While we did receive confirming data about our overall goals , we also received crucial feedback about confusion with some of the features as well as ways to add to features that we had not thought of . We were able to meet with developers and quickly change our approach . We also learned an important lesson for adoption : two out of the six testers did not follow the instructions . That tells us that we should expect about 20 - 30 % of users will not fully read or understand our launch or onboarding instructions . We have since edited our full launch plan to include multi - media methods to explain instructions . The silver lining is that , although the two testers did not follow the proper instructions , we could tell that they still used the platform as it was intended . This proved our ultimate goal that , while users may not thoroughly read instructions , the platform itself is user - friendly enough not to require extensive instructions in the first place . Approach While the learning launch was the best tool to use in at this specific stage for our challenge , in retrospect we should have incorporated design thinking tools to our original challenge . We should have incorporated our intended users in the process of defining the problem we were trying to solve before we started working with developers . If we had started with the mind- mapping tool to help communicate on the same level and then incorporated visualization to achieve our first prototype , we may have been able to launch a product without as many “ pivots ” . Still , it was a valuable lesson to see that even if you do not start a project with design thinking tools , you can still pause and use them to back track and test assumptions before it is too late .