UX for the Team
The best way to ensure a team produces a product smoothly is to ensure that the team has a good “user experience”.
What do you do when you see an unreadable design plan?
All of this started out with one of my designers showing me their messy sketchbook sketch of our character’s conversational logic that they had been basing everything on.
While starting a FigJam board to show my designers how to organize dialogue, I created the first conversation and realized that this could be just the tool the design team needed!
I created a system where anyone can pick up the board, designer or not, and know what is going on. From location cues to help the engineers know where to put the conversational colliders to emotional cues for the AI.
Everything is laid out and coded in a way that any of my team members can add to it as well, making it a collaborative tool and fundamentally a way for us to communicate.
Preliminary mock-up done by my colleague Kieran McKee
Asset Tracking
Checklists and Sanity
As we all know, tracking priorities on a project is key. I decided to make a document that was first used for the design team to figure out everything we wanted in the game. This includes writing down Affordances, Signifiers, and Feedback (ASF) for everything. This means that we had an easier time communicating our content needs to art, sound, and tech.
Color coding and a key were added for usability. One of my priorities was that anyone could take a glance at this sheet and know exactly what was in each category, ‘A’ for highest priority, ‘B’ for medium, and ‘C’ for lowest. The team could also look to see what exactly had gotten checked off task-wise.
Just because it is in a document though, doesn’t mean that our job is done. I wasn’t making this process in a vacuum, so it ended up changing over time through feedback. By the end of the first semester, the color coding had changed to be easier to see at a glance, sections were organized in an order that was requested, and sections that were specifically for art or sound were labeled as such.
However, because I care more about how useful a tracking tool is for the team, and less that it is my tool, we ended up using ClickUp instead for the second semester. That came with its own issues, but through trial and error, we found that the team felt more comfortable updating our ClickUp. This was also more necessary the more detailed our tasks became. The list I had made was more of an umbrella for all mechanical and design ideas, so we moved them to the design doc and kept them there.