Streamline and simplify the convoluted process by reducing the number of steps and increasing collaboration between the user groups and platforms. Provide a user-friendly interface with consistent interactions that would allow both parties to achieve their goals with confidence.

These are the craziest days! On the first day, we have our first internal meeting to get everyone up-to-speed on the problem and the specific use cases (my manager and I like to review the sprint brief a few days before to feel more prepared). Then the discussion starts. It's a safe place where people think of ideas or solutions, and others bring up important points that could support or challenge those ideas or solutions. It's highly collaborative. After the meeting, the designers go back to our workspace and sync up. This is when we come up with the solution concepts and start producing sketches and lo-fi wireframes.

On day 3, the designers present the possible solutions in the form of wireframes. We walk through the flows (just screens at this point, no prototypes yet) and gather everyone's feedback. Did we capture all of the use cases? Do you see any potential issues with these solutions that we are proposing? Which solutions should we move forward with?

Depending on the type of feedback we receive the day before, we may have to go back to the drawing board and come up with new solutions. Sometimes, we just need to make tweaks, big or small. After fleshing out the details, the designers create interactive prototypes that cover all of the use cases. We then share and validate them internally. After that, we do user testing in the client working group to validate our solutions.

The design sprint comes to an end! The last day is reserved for a retrospective and feedback session, which the designers own and lead. We ask what went well, what can we improve on, and what we should show more or less of in the following sprints. I appreciate this "continuous improvement" approach. It's in this meeting where we decided to try out having a two-week sprint because we thought we could use the extra time to produce more polished work. However, in the end, we decided that having one-week design sprints worked best.

Design sprint was a lot different than PI (program increment) sprint in that I had the creative freedom to come up with as many ideas as I could without a lot of restrictions. Of course, the solutions had to be technically feasible, and that is why we had two engineers in the internal discussions. Although these sprint weeks were jam-packed with deliverables and meetings, those were also the most exciting, inspiring, and productive weeks.

Initially, we had trouble getting feedback from customers. We would share our forward-thinking designs in the one-hour working groups following each design sprint, but due to the amount of work we had to share, we would often run out of time for feedback. After two lackluster working groups, I made a suggestion that we utilize the client working groups to do user testing. Rather than just going through our interactive prototypes and explaining our rationale, we would ask the participants to perform specific tasks using the prototypes. The groups were relatively small - consisting of 2-3 people - so this method was effective. It also sprouted engagement from everyone on the call.

The other challenge we initially ran into was collaboration. This stemmed from my manager working remotely in Houston, TX, while everyone else on the team worked out of the Austin office. Communicating and brainstorming ideas together became difficult at times due to distance. Therefore, we used a tool called Miro to combat this. This platform allowed us to build user flows together and share comments in real-time. In addition to that, my manager drove to Austin for the last two design sprints and spent the first two days, so that we could brainstorm and do sketches together in person.