RogueCraft Squadron Game 2017-2019

Why I got into UI/UX design

Video Preview

Let me tell you a story.

It began with a game idea built in 3 days.

So here is the game, I think it’s really cool and I’m like where can we show it off?

SXSW perfect. I get my team a booth for free by networking and we show off our game.

Boom! Success story right??


Let me tell you why games fail. And what to do about it.

Scope ~ forever – Budget ~ who cares – Role ~ artist/designer

The Brief

RogueCraft Squadron or RCS for short was originally a short game jam. I did the art, it pushed me in something I always struggled with. Consistency. But I wanted to build this game into a real full fledged game, I convinced my programmer to keep working on it. Great idea right? Well it could have been but… There were a few major issues that never were addressed.

Problem Statement

So here we have this game, it’s cool, interesting concept but what problem is it trying to solve? Now hold up you might say, games solving problems? Games don’t solve problems. Yes, actually they do, let’s think about this. What is the opposite of something failing to solve a problem? A clone, a knockoff, a cheap and fake product that fails to address user needs. How was our game addressing the problems in the marketplace? How do we distinguish ourselves? We didn’t. We were basically a clone with a minor gameplay tweak. Big red flag, we didn’t know what we were trying to solve. Why didn’t we know this? Let’s see if you can figure it out.


We had a solution though, after years of work we finally released something. We had tons of people test it, give us feedback, and we worked in some of it. How do you know what the best feedback is? Is negative feedback important? Positive feedback? What is the best use of your time? We gave it a guess and pivoted a lot to come up with a multiplayer real time strategy game.

The Process

Design Process Double Diamond

This is what good design looks like. In the Discover and Design phase you will prototype and see if the audience likes your idea and if the market will support it. But I had never heard of this, I didn’t have a background in UI/UX design. So what did we do? I call it the H software dev cycle aka mindless testing and designing at the same time.

H software development
Testing mindlessly

So this H cycle was great in that we got a lot of feedback, but the feedback was all over the place. We had no set goals with the feedback and were just looking to “make the product better”.

What is better though?

Without clear goals and reasons to follow those goals you can easily fall into feature creep (FE) and underdesign (UD).

You focus on adding too many features that were not planned out which often causes underdesign or poorly designed products or experiences.

How to tell if your project has FE and/or UD

Does your project suffer from frustration? Do you suffer from communication issues or distrust? Do you suffer from brain fog and lack of direction? Do you feel time constraints or lack there of? Can you easily prove why the work you are doing is important? Do you feel your project is organized enough you could hand it to someone else without explaining a lot of it? If not your project might have FE and/or UD symptoms.

How to solve FE and UD

FE and UD are hard to tackle once they infect a project. Often they start off as harmless ideas that grow into a desire to cheat by working on the “fun stuff” or focus on fulfilling a personal goal that the user would not care about. UD especially comes from time pressure, lack of prep work and lack of organization.

Steps to solving FE and UD would be focusing on the user and business needs, this can be done with the following methods – survey’s, market research, personas, interviews, problem statements, how might we’s, wireframes, user testing etc. You can wrap this up into something called User Experience (UX) and this validates why features are important.

Something else you can focus on is design systems. Design systems help organize work to bring clarity, direction, save time and help with communication.

Did RCS eventually use UX methods or design systems?

No and it was painful not having these systems. I had never heard of most of them, especially in games.

Style Tiles

Towards the end of development I started creating a template for my art assets. Yep. Took a while. I ran across something while browsing online to find better methods and it was called a Style Tile. I ended up making one.

Style tile example for RCS

At this point though art assets were all over the place, we had changed direction so often design, art and code wise it was hard to make sense of the art style anymore. It became too hard to pivot because of technical debt, design debt and art debt. Basically, we have gone too far in one direction to change now because the cost and work is too much.


Wireframes. I created a fair amount of hi-fi wireframes, often I have to figure out the content so I don’t work in lo-fi very often and RCS was no different. I created a variety of wireframes, not all of them made it into the game but I figured I’d show some of them anyway. This was before I knew about proper UX/UI tools so YEP made everything in Photoshop. Horrible way to design but I didn’t know better tools at the time.. Nowadays I use Figma for everything.

Lobby Wireframe in progress
victory screen stats
Victory screen in progress
Wireframe for action menu
Wireframe in progress for action menu

User Testing

User testing… Well about two or three times a month for like 3 years we would gather feedback on what we changed in the game and tried to market the game at the same time. I’d say user testing was very helpful for the tutorial we did eventually create but because we were not sure what to test for our user testing was often not helpful and our audience was basically anyone who wanted to spend a few minutes playing at our booth. We would ask users questions and help them walk through certain sections until we got a working tutorial up. Our tutorial system was on of the few that we actually tested to see if the user could pass set tasks and we would ask them what they thought about certain tasks.


What went well with RCS was tons of user testing and interacting with a variety of users in different places and in different ways. But everything else really needed a design process. We started with an MVP idea of what we wanted for the game but missed a lot of Why, Who, What, and When because we didn’t use a design process to really think about the idea before diving headfirst into it. We didn’t have a strong grasp of who to market too (no SWOT or market research), no great idea of what problems our game solved nor ways to standout. We struggled, pivoted and reworked code, art and design often because the design was UD – Underdesigned. I was always playing catch up trying to design the game as we went which caused a lot of long term problems. Had we, from the start sat down and designed this long term it would have made for a much better design experience from the start.

So why did we not do better?

Lack of design and system designs in place. Lack of long term goals and a problem & solution focused mindset. So this is why I started to study UI and UX because I saw what I was missing and I experienced the pain of it.

Ashley Hooper