Designed by Tera Nguyen

Piggy Banksy Live! - A Multiplayer Experience on Art and Provocation

at the Games For Change Festival - June 18, 2019, NYC

ROLE

Co-Producer

TEAM

2 Engineers

3 Designers

1 Co-Producer/ Narrative Designer

DURATION

16 weeks, 2019

CLIENT

Games for Change

PLATFORM

20 iPads

2 big displays 

1 projector

TOOLS

G Suite

Physical notes

Website

Dev blogs

MY CONTRIBUTION
  1. Defined success metrics from ambiguous information

  2. Aligned team on creative vision and kept track of progress

  3. Applied agile processes to ensure timely and high-quality deliverables

  4. Organized playtests to validate ideas and resolve conflicts 

  5. Prioritized tasks to optimize our process with available time and resources

  6. Recognized individual's passion to make my teammates happy and productive

  7. Developed website content and weekly development blogs to engage stakeholders and audience

PROJECT SUMMARY

a digital collaborative art experience that encourages players to find their inner provocateur to create the social change they want to see in the world. Players are asked to reflect on why they came to the Games For Change Festival, what social issues they would march for, and how to start their own creative revolution through the power of art. [CMU - Playthrough]

THE CHALLENGES

Make decisions with ambiguous information

Ambitious designers with many ambitious goals

Limited time (16 weeks) and resources

THE SOLUTIONS
[1] Defined success metrics from ambiguous information

The core of this project is to design with practicality - how to implement an experience successfully at the space and to the audience we had. Before the team dived into brainstorming, I laid out all the project constraints so we could find the strongest use case for our project.

 

We often challenged ourselves with questions: Why are we making this? Who is our target audience? What makes our product unique to our audience compare to existing ones in the market? How does this feature achieve the product’s goals? Our initial success metrics eventually grew more robust and guided us through our decision-making process.

Getting the team to see eye-to-eye on the answers to these questions/metrics was crucial to deliver our experience successfully.

[2] Aligned team on creative vision

To keep everyone's vision aligned, I asked my designers to sketch and deliver paper prototypes. Low-fi prototypes were quick to make and easy to modify, which enabled us to be flexible with our design. I also documented our daily learnings on the whiteboard and 24"x16" post-it sheets. Our internal workflow and getting buy-ins from the faculty and client were very efficient.

Questions I asked myself everyday at work:

  • Does everyone know what they're supposed to work on and when are their tasks due?

  • Is everyone informed with what other teammates are working on?

  • Does everyone know where to find the information they need or who to talk to to get that information?

  • Can everyone present our project vision to stakeholders?

  • Is there anything blocking anyone from working effectively?

[3] Developed production schedule & agile processes

I created the production schedule and applied agile processes to ensure timely deliverables from my team. 

Processes that worked well: 

  • displaying physical meeting notes and design artifacts;

  • design by committee for major design decisions;

  • distributing features to a smaller team of one designer - one programmer; 

  • interviewing experts for feedback only when necessary.

Processes that did not work well: 

  • too many expert interviews 

  • digital meeting notes (without physical notes),

  • normal work hours. (my teammates had different work schedules)

New processes that got added: 

  • Weekly one-on-one conversations (eat together, coffee walk, play games) 

  • No tardiness on playtest days. 

Things I heard or observed that helped me evaluate my processes:

  • Lack of team alignment

"I don't know what person X is doing!"

"I'm not sure I understand why person X does this."

  • Lack of preparation

"Not sure what to talk about in this meeting, or if this information is directly useful to me." 

"Too many meetings, and not enough meetings."

 

  • Lack of effective documentation

"Which "latest UI version" do you mean? I can't tell the differences between the two versions." 

"Why did this person choose this solution, or that solution?" (repeat x times)

"Let me find my file on the system." (10 minutes later - still looking for it)

"How do I document this?"

  • Lack of ownership

"Everybody has an opinion on design."

"I had to discuss with person X, Y, Z in order to deliver this feature." (which took a long time)

  • Lack of trust and collaboration

"I am afraid to bring up my thoughts that could be seen as negative to person X."

"We can't give any feedback to person X."

[4] Resolved conflicts

Conflicts are expected to happen when working with interdisciplinary teams. When they occurred, I talked to my teammates to understand the source of these conflicts and their impact to the project's objective. I also did the following:

  • organized playtest to quickly evaluate

  • involved other team members to understand the pros, cons, and dependencies

  • brought in superiors' opinions (faculty, client, topic experts)

  • put in product backlog to prioritize more time-pressuring milestones 

[5] Prioritized tasks & managed risks

I relied on three factors that enabled my team to prioritize tasks after every playtest. I also broke down the list of tasks into smaller chunks that could be built and playtested every 2-3 days.

Time: What were the most time-sensitive tasks? What could we fix and playtest in the next 2-3 days?

Impact: What features could make or break our product?

Resources: How many people do we need to complete the tasks and how much time required to complete them?

[6] Recognized individual's passion

Because designers' work are deeply fueled by individual passion, I bonded with my designers by: 

  • assigning the right person on the right role to give ownership

  • accommodating personal schedules to show understanding

  • organizing weekly playtests to create challenges

  • enabling design by committee for major decisions to show respect

  • applying deadlines to give pressure 

  • arranging seating to allow daily conversations

  • having one-on-one coffee conversations to give and take feedback

  • being transparent about our decisions' outcome and tradeoffs to keep everyone aligned

[7] Developed weekly blogs and project website content
MY LEARNINGS
  1. Fail fast with a purpose - Find fast and easy ways to playtest your design. This is a great way to resolve team's conflicts. Make sure to have clear testing metrics to avoid wasted time and effort.

  2. You are not alone - Stakeholders are a great resource to give you insights on whether you're doing it right or wrong. Don't hesitate to ask for feedback. 

  3. Trust your team - If the team is passionate in a vision, you have a higher chance for stakeholders to buy into that vision. 

  4. Enable ownership and show appreciation - Allow everyone to take ownership of their work and show them their impact on the project's success. A simple "thank-you" or praise goes a long way.

  5. Know "when" (Processes are only effective through iterative and consistent implementation) - Find out what works with the team and be consistent in using it. The trick is to know when to implement and when to iterate. If your processes are not useful to your teammates, you will see the team react to them.

  6. Have deadlines to enable prioritization - Time is a powerful pressure for decision-making process.

  7. Have a weekly retrospection - Don't forget to reflect on the team's weekly process and optimize it for better efficiency.

  8. Interview experts and users - Learn about their process and pain points. Do NOT ask for design solutions.

  9. Don't just tell, participate! - If you want to have something done, participate in solving the challenge with your teammates.

  10. Learn more tech - I was strong in facilitating design discussions more so than tech discussions. I learned a lot from this project on iOS development and backend architecture. Having this knowledge prior to the project would enable to help my programmers make decisions faster.