International Personnel Exchange Program

CHALLENGE / PROBLEM

Business Problems

  • To facilitate personnel exchange between the loosely affiliated community bicycle workshops in the western hemisphere. And to benefit each other by sharing, learning skills and provide better cultural understanding.
  • No unified body working directly on the problem. Rob stepped up and had the skills to take this beyond just questions and planning.
  • To be able to flesh out the ambiguous challenge on an international scale into something attainable and sustainable. Also to get more of the stakeholder community involved.
  •  

Designer Challenges

  • Stakeholders were unfamiliar with tools and processes being used. They had a hard time cooperating during brainstorming workshops. Rob had to work with their limitations so they felt supported enough to share their insights.
  • Became a web-based project due to stakeholder locations. That meant communicating through the net to get work done and making all material easily available online.
  • The project was being built for multiple autonomous nonprofit organizations. There wasn’t one group responsible for the upkeep. That meant it had to be as easy and inexpensive as possible to maintain, relying on a consensus method of approval for decisions.
Screen Shot 2019 02 07 at 10.41.31 AM 1
Developing the journey map for the international personnel exchange for the bike collectives community
Service Blueprint for International Personnel Exchange for the bicycle collectives community
Full Core and Enabler Service Blueprint for International Personnel Exchange for the bicycle collectives community
CommunityBicycleWorkshopExchange_page_01
Business Model Canvas for International Personnel Exchange for the bicycle collectives community

ACTIVITIES / ACTION

Design Methods Used

  • Service Blueprint
    • Reason for use: to have one place where relevant information would live & could be referenced; as well as providing an idea of how the service would look fleshed out.
    • Challenges: getting stakeholders to think in broad terms about the whole service rather than only what it will take to get it built. When this didn’t work, it came to focusing on small sections to get their insights. Also, getting stakeholders to understand the difference between what was core, enabling, and enhancing to the challenge.
    • Successes: A strong core and enabling blueprint to keep to what was important to the challenge, as well as a master blueprint to maintain a record of all stakeholder insights. The minimum viable product was pulled directly out of the core blueprint.
  • Storyboard
    • Reason for use: this was the initial prototype and the first thing to be put in front of stakeholders so they could begin to see how the service would play out.
    • Challenges: getting consistent feedback remotely. When sent to groups Robert only received, “looks great”. When sent to individuals, more useable feedback tended to follow.
    • Successes: gaps in the service were identified. A visual of what the service could look like was produced. It only took two hours to produce. Feedback from multiple countries and states. Stakeholder’s roles were identified and addressed.
  • Business Model Canvas
    • Reason for use: to quickly plot out processes, costs, resources, revenue possibilities, people involved and to see how doable project would be on one page.
    • Challenges: not all stakeholders were available to weigh in on the canvas and some information had to be guessed at.
    • Successes: a rough annual cost was determined, as well as core processes that would have to be handled, all presented in one easy to read documents.
  • Marvelapp’s Prototype on Paper
    • Reason for use: inexpensive application that allowed an easy build of an interactive prototype of what the web presence would look like and how it could behave.
    • Challenges: some stakeholders felt Marvelapp to be suspect and untrustworthy. Robert had to learn the app on the fly and create versions in multiple languages.
    • Successes: interactive prototype built. It was accessed and played with from multiple states and countries. Versions in English, Spanish, French, and Portuguese were produced.

New Things Tried and How They Worked Out

  • Stakeholders weren’t interested in looking at the service as a whole, so Robert encouraged them to talk and share. This got insights that were more focused in one area of the service rather than a well-rounded view. He also encouraged silly suggestions for participants to riff off of. This worked great.
  • Had to switch to sending prototypes to people individually rather than to large groups. This tended to get people to be more responsive with feedback and insights rather than being quiet and thinking someone else would speak up.
  • Switched from drawing out web elements to creating them digitally in Marvelapp. This didn’t have as much personality but saved a huge amount of time and provided much more ease of use.

Overcoming Design Challenges

  • Making every step count due to minimal budget
  • Small incremental iterations with user testing
  • Used the service blueprint as a reference to stay on track

Challenges Were the Process Had to be Modified Midstream

  • Stakeholder service blueprinting and ideation workshops
  • Receiving prototype feedback remotely
  • Creating prototypes on paper by drawing then placing in Marvelapp.

Dealing with Political Challenges

  • Stakeholders claimed they had already done the work. Robert had to be supportive of this and then get them to share what they had done so it could be analyzed and woven into the project.
  • Some stakeholders were vocal about what they wanted but would not weigh in on the prototypes. Robert took their comments into the blueprints and found stakeholders who would share experiences at using the prototypes.
  • Some stakeholders were vehement about prototype needing material outside of enabling the core of the challenge. Robert stated that he was unable to work on that material up but would gladly include it if they would provide it, which they did.
  • All the organizations involved were working together by consensus. That meant learning how to operate within that decision-making model.

Dealing with UX Skeptics

  • Robert found allies in the stakeholders who understood the process. They had sway with the other stakeholders and recruited them as champions to share their voice.
  • He recognized and supported skeptic’s views during workshops rather than fight them. He focused on their stories to pull insights from.
  • Found those who would cooperate and leveraged them.

 

OUTCOME / RESULT

How It Was Received by Users

  • When prototypes were sent to large groups remotely, the analytics said they getting attention with but no one shared their thoughts.
  • When he reached out to specific users individually they were much more forthcoming with feedback.
  • Users in Mexico, Brasil, Argentina, and Montreal felt alienated due to prototype being in English.

How It Was Received by Coworkers

  • My graphic design partner loved the simplicity of it.
  • The software developer did not do the testing they said they would.
  • There was difficulty following the comic-style storyboards. They needed to be more clear-cut and linear.

How It Was Received by Stakeholders

  • Some were suspicious of third party apps used.
  • Most liked the direction the solution was moving in.
  • Several were very adamant about adding in multiple languages and information about visas.

Product Performance

  • It provided a minimum viable product to facilitate a program.
  • The web app was well received but needs more iteration.

User Feedback on Prototypes

  • Users desired to interact with the prototype on a deeper level than was allowed.
  • There was some conflict over including a section about background checks in the application forms.
  • Some users wanted the app to do more than could be sustained.

How It Was Received by Stakeholders

  • Some were suspicious of third party app used.
  • Most liked the direction the solution was moving in.
  • Several were very adamant about adding in multiple languages and information about visas.

Impact of UX Within the Organization

  • Journey mapping workshops were well received and looked at as a tool that could be utilized to break up processes and target efforts.
  • Members reached out to see how to develop blueprint for their own projects.
  • New organizations reached out to contribute after hearing about the project.

Role Successes and Impacts

  • Accomplished in a few weeks what the group hadn’t in several years.
  • Stronger working relationships were developed with teams in Guadalajara, Montreal, Portland, Toronto, and Chicago.
  • Stakeholders now have a holistic view of what the experience of a personnel exchange could look like, cost, and maintain to move forward when they are ready.

Project has not gone to market yet.

Mobile view of web app prototype for international personnel exchange 2 1