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”. This is something I care about greatly. UX for the team may include easily understood and accessible documentation, presenting data in a digestible manner, and creating systems to help the rest of my team do their jobs more efficiently.
Conversational Logic
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 Barton’s conversational logic that they had been basing everything on.
I decided to start up a FigJam board to show them how organized they could be in making this plan. I created the first conversation and realized that this could be just the tool the design team needed. It went from a messy sketch from one designer trying to plan out the hard-coded conversations that Barton should be having with the player, to an organized system that the whole design team now uses.
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.
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.