Help Me, Help You: UI/UX Edition
UI/UX (User Interface/User Experience)is not the most glamorous position in game development. I made the transition from a 2D Artist to a UI/UX Designer/Artist mostly out of circumstance, and somehow stayed because I ended up finding it fun.
As the go-to UI/UX person working on Disney Melee Mania, the scope of my work is very broad. Working in a small-to-medium studio like Mighty Bear means that many of us have to be prepared to put on many hats everyday. On some days, I would be more focused on designing user flows and working on paint overs and graphic design stuff, while on other days I would be troubleshooting bugs and dealing with the implementation of a UI feature in Unity. It’s challenging, and every day is a new opportunity to push myself as an artist and as a designer.
It’s not all just about the UI/UX process though. The largest challenge (and joy) for me isn’t about designing the prettiest icon or making that sweet transition animation — that’s a basic requirement of the job. As UIUX folks, we can bring one more thing to the development table: ensuring that we support our teammates and helping them to work better.
UI/UX doesn’t carry, we support!
My work is almost entirely collaborative — locking yourself up in the fortress of solitude and just working on a task for most part not an option. Even the tool I use for most of my work (Miro) is geared with collaboration and visibility in mind.
The UI/UX team in Mighty Bear runs with a few key principles in mind:
- We have to be dependable supports for engineers and designers
- We have to be clear and transparent with the team regarding our tasks
- We stay relevant to trends in the industry
- We have to design good UI based on solid UI/UX principles
Notice how two of the four principles relate to the UI/UX team in relation to everyone else around us. Half our job is to ensure that we help others work better. These principles were extremely important in guiding certain workflow efforts that I made while working on Disney Melee Mania.
Clearing ambiguities
Working with people from different disciplines often means fine-tuning your process to ensure everyone understands the intention of your design. What matters to a designer or an artist might not be what an engineer needs to know when they are implementing the feature.
This can be as simple as always having different visual aids depending on who you might be presenting the design to.
When talking to designers, I tend to just present user flows and try to show more than just the “golden path” scenario (always plan for the worst). At this stage, I also tend to provide more than one solution to problems so that there is still room for back and forth.
After this comes the handover to the engineers. We try to have locked down the issues that design and stakeholders have as much as possible by this point, so that the concerns can be more about the technical implementation. In addition to flow diagrams, I also include screenshots of the UI set up in the game engine.
If I’m presenting specs to artists, I will try to create paint overs to visually show them the intention.
Speaking of intention, it is also important to note that at every stage of this process, it is good to be clear what the intention is. You never know when someone can make a good suggestion down the line! Also, getting everyone focused on the problem that you are trying to solve can cut down on time arguing about issues that are not part of the problem scope.
This is more work on my part as a UI/UX Designer, but ensuring that everyone is on the same page with the same expectations prevents more grief further down the line.
Ensuring clarity upstream of the pipeline has many implications for teammates working in my downstream. For engineers and artists, having exact details on the task means that they can more accurately see what is needed and estimate the amount of time they needed. Having exact visuals can also allow engineers and artists identify whether a task is feasible. It was also extremely useful in identifying any edge cases that we might have missed out.
Clarity in documentation also helps you as a UI/UX designer. In a perfect world, I want to be able to remember everything about any feature or design I created, but when said design was done 5 months ago, I’m definitely not going to remember it with my hamster brain. Documenting my work has saved me more than a few times when I had to revisit or improve on features that I had worked on previously.
Be Adaptable
As UX designers, we have a lot of tools available to us. We’re always trying to find that one unicorn that can meet all our needs. Having tried a bunch of these, I’d say it’s not about which tool you use, it’s about what the team needs. What might work in developing apps might not work as well for a game with more complex and varied interfaces.
For example, in Disney Melee Mania, something we wanted to try was to have the UI look more 3D. After sparring with Photoshop for a few days and creating janky perspective mockups in 2D… I gave up and just started mocking my work up in Unity, which had the exact 3D perspective I needed. With deadlines and the need to still ensure some semblance of a proper design process, it is essential to know when to stop and move on. Blocking downstream work means delays and potentially causing confusion in planned production timelines.
Choosing what tools to use is often a hot topic among designers, but if you happen to join an ongoing project, most teams should already have tools and programs that they have been regularly using. It does not make sense to overhaul entire workflows just because “Tool X can do more than Tool Y”. So being able to adapt your process to different tools and projects is something UX designers in smaller teams have to keep in mind, especially in Game UI/UX, where technical limitations and specs can vary greatly across projects.
That being said, it doesn’t mean we can’t try to find new programs that can help us in getting our jobs done better. It’s just a matter of timing, and also getting the rest of the team on board with it!
BTW, I’m here for you
A few months ago, Mighty Bear’s former engineering intern Kevin posted an article on his experience working on UI programming. Huge chunks of his article were about communication, and for good reason.
Earlier, I wrote about clearing up ambiguities by documenting things as thoroughly and as clearly as possible. However, as much as we try to ensure all our documentation is complete, there will always be something we missed out. There will always be that ONE thing we forget to document that bites us later on. Being a dependable support sometimes means we just have to be there to answer these questions.
Some basic things that I try to do often as part of my role include:
- Providing regular updates on the state of tasks. Raising any delays early so that contingencies can be made
- Checking in on the progress of tasks once they are out of your hand
- Ensure that Slack channels have your Miro board bookmarked. Also always add screenshots and provide context.
- When in doubt, approach an engineer early (not doing this has bitten me in the behind more than a few times)
Many of the points above are things that anyone working in a team should be doing, but if you keep in mind that a UI/UX designer is basically the lubricant that makes the machine run smoothly, you’ll realise that communication becomes a much larger part of the job scope.
Something that the UI/UX team here at Bear Force One has been trying to cultivate is the idea that no specific team owns UX — everyone does. That means that everyone, whether you are a designer or an artist, can have a say in the experience. Anyone can raise issues and everyone can bring up pain points in an experience. Keeping an open channel of communication and not shutting out critique has helped us identify issues that were difficult to raise, all to make a better product (and a better team).
Iterate and Polish
Just like a feature, processes have to be iterated on. Every new task we do is a new opportunity for us to check if we’ve kept to the pillars of the MBG UI/UX team
- Evaluate what has been done
- Plan out any future changes
- Rinse, repeat, try again, iterate
The process of improving our personal workflows and processes is the never ending task of any designer. Every team, every company, and every project is always different with new challenges and limitations. This write up doesn’t even cover other potential improvements to our processes, like building a library of reusable components, or creating a UX framework that we can apply across various MBG projects. Hopefully these are topics that we can cover in later Medium articles!
I hope this write up gives you some insight on the principles that helped guide me while working on Disney Melee Mania. We’re still working on improving the game so download the game and join us on Discord! Otherwise, if you’ve enjoyed this article, share your thoughts in the comments below, or drop me a clap. Thanks for reading!
Help Me, Help You: UI/UX Edition was originally published in Mighty Bear Games on Medium, where people are continuing the conversation by highlighting and responding to this story.
