one of the hardest diplomatic skills i think game designers should learn is how to ask your team for assets to support a prototype when you don't have full confidence the prototype will work out. this happens a lot in development-- you have a hypothesis you want to test. (cont'd)

it's a good thing to try out several possible directions for a feature (if those directions have some merit) whenever you can. but often this will require someone else to give the designer some supporting assets: an animation, a sound effect, some vfx, or some new code/component.

in the best possible scenario, your team is equipped with a large 'DIY' library where designers can easily pull vfx/sfx/retarget animations to fit a variety of temp or prototyping needs. some projects i've been on have this. some do not, and then the convo gets harder.

things i think help make this work feel less painful for the artist/engineer/audio person who will give you assets:

1. clarify your confidence in this feature up front. a prototype you have 85% confidence in is very different from a hail-mary wouldn't-it-be-nice 25%.

2. intentionally ask for bad. sometimes craftspeople, especially in AAA, like to *always* go hard and give you something amazing. i usually try to frame the convo as "please give me the quick and dirty thing, because there's a likelihood it gets cut if this doesn't move forward."

3. try to ask for assets which aren't hard-coded to your specific use case and can be flexible if the needs of the prototype change. e.g. a "windup" sound effect which is set to exactly 3 seconds, vs. a more generic "looping windup" --> "burst" which can have a variable length.

4. make sure this convo is happening with your producer's visibility, for traffic control. asking an artist who is already overbooked to make you extra stuff is a very bad look. your producer SHOULD be able to help you carve out prototype time if you can make a case for it.

(and to be clear, the "making a case for it" is also part of your job as a designer. if you can't demonstrate the thing has value and sell your team on the value of spending some time prototyping it, well, that's a whole 'nother skillset.)

5. learn who CAN do "quick and dirty" on the team. some folks will always just give you gorgeous 10/10 work and then get bummed when the prototype gets killed. some are like "i checked in something basic i did in 10 mins, hope the prototype goes well." you want the latter camp.

6. realize when you're being disrespectful of someone's time. do you really need to ask your sound designer to rework that prototype sound 3, 4, 5 times? can you just squint and see how a different sound would work better if this feature moved forward? if you can, do that.

the goal of the prototype isn't to feel perfect, it's to get you enough of the way there that you say "ok, we proved we want to do this feature for REAL, let's get the gang together and re-evaluate what we need here." be a good partner to your teammates. don't be a perfectionist.

and, lastly, 7: make sure everyone really understands the GOALS of the feature, not just your specific proposal/design for it. i love it when my teammates are like "you asked for X, but now that i understand what you want from this i think Y is better." often, they're right.

what goals are not: a literal description of the feature

what goals are: the player behavior this feature should evoke. the reasons why a feature like this would be healthy for the game.

give your teammates space to suggest something different or better, and they often will.

anyway, i learned all these lessons the hard way by bumbling through every bad behavior in the "baby's first prototype" handbook, so learn from my mistakes and go forth and make delightful things!!