This is a reflection of how I did not use design thinking tools.      CHALLENGE    Years ago, I was working for an organization with hundreds of team members around the  country who needed to submit daily compliance paperwork.  Their hundreds of reports were  aggregated into one overall report that was then submitted to the appropriate regulatory  agency.  Being late, or supplying inaccurate information, could lead to fines or other  penalties.  While today there are several existing options, at the time, there were no products on  the market that met our specific needs.    We concluded that we needed to develop a portal for team members to submit their reports via a  website or mobile app, which in turn would generate a master report for the organization.  A  portal would eliminate lag time in submissions and human beings having to cobble together  hundreds of different reports.    At the time, it was just the beginning of spring, and we needed everyone to be using the portal by  the fall.  We planned to use the spring months to develop the software and train team members  over the summer.       SELECTION & APPLICATION    We chose to build our software in-house and immediately launch it nationwide upon  completion.  There was no need to test our assumption about how team members would use the  portal since we were confident in how team members would use the portal and react to the user  interface.  We knew them and had previously been one of them.  Getting their feedback in the  design process was unnecessary and would only slow us down.    Some might argue that we should have used a learning launch to test our hypotheses and gain  feedback from the end-users, but we knew better.  The portal was developed throughout the  spring and rolled out to team members in early summer, along with a lengthy memo instructing  them on how to use the app and website.      INSIGHT & APPROACH    You’ve probably guessed that thing did not go well.  With roughly 10% of our team members  using the portal properly after several weeks, it could be considered a disaster.  The vast majority  couldn’t even figure out how to use the app or website.  What made matters worse was the  remainder of team members misusing the portal and filing incomplete reports.    Fortunately, abject failure humbled us.  We realized that while using portal made sense to us, the  developers, we didn’t truly understand how other people would attempt to use it.

Quickly going back to the drawing board, we used the rest of the summer to test specific features  on groups of team members, and push out small changes every week or two. This led to  removing options from the portal and streamlining the user interface.  By September, we had  about 97% of team members correctly submitting their reports through the portal.    Had the development team used a learning launch process to test our design hypotheses from the  beginning, we would have had much less stress and much more sleep that summer.


This is a reflection of how I did not use design thinking tools . CHALLENGE Years ago , I was working for an organization with hundreds of team members around the country who needed to submit daily compliance paperwork . Their hundreds of reports were aggregated into one overall report that was then submitted to the appropriate regulatory agency . Being late , or supplying inaccurate information , could lead to fines or other penalties . While today there are several existing options , at the time , there were no products on the market that met our specific needs . We concluded that we needed to develop a portal for team members to submit their reports via a website or mobile app , which in turn would generate a master report for the organization . A portal would eliminate lag time in submissions and human beings having to cobble together hundreds of different reports . At the time , it was just the beginning of spring , and we needed everyone to be using the portal by the fall . We planned to use the spring months to develop the software and train team members over the summer . SELECTION & APPLICATION We chose to build our software in - house and immediately launch it nationwide upon completion . There was no need to test our assumption about how team members would use the portal since we were confident in how team members would use the portal and react to the user interface . We knew them and had previously been one of them . Getting their feedback in the design process was unnecessary and would only slow us down . Some might argue that we should have used a learning launch to test our hypotheses and gain feedback from the end - users , but we knew better . The portal was developed throughout the spring and rolled out to team members in early summer , along with a lengthy memo instructing them on how to use the app and website . INSIGHT & APPROACH You ’ve probably guessed that thing did not go well . With roughly 10 % of our team members using the portal properly after several weeks , it could be considered a disaster . The vast majority could n’t even figure out how to use the app or website . What made matters worse was the remainder of team members misusing the portal and filing incomplete reports . Fortunately , abject failure humbled us . We realized that while using portal made sense to us , the developers , we did n’t truly understand how other people would attempt to use it . Quickly going back to the drawing board , we used the rest of the summer to test specific features on groups of team members , and push out small changes every week or two . This led to removing options from the portal and streamlining the user interface . By September , we had about 97 % of team members correctly submitting their reports through the portal . Had the development team used a learning launch process to test our design hypotheses from the beginning , we would have had much less stress and much more sleep that summer .