On Register is one of several projects that emerged from an intense prototyping period at Simcoach Games that focused on vocational skills and life skills.

On this page you’ll find
- Details that highlight my ability to design the user experience

- Examples of how I communicate and explore concepts with teammates

- How I helped make decisions about iterations based on playtest feedback

- Many examples of UI design

Continue reading for an in-depth review of my contributions to the project's development.

After deciding that we wanted to build an experience to help people practice using POS (point of sale) software, the first question to answer was, "What is POS software?"

Some of us in the studio have experience working behind a register, but those days are long gone. So, while our personal experiences could potentially provide some insight it was more effective to explore online.

Fortunately, POS software is a product so there's no shortage of publicly available photos, footage, discussion, and tutorials about the different types that are most commonly used. Here are some screenshots from references that I found online:

Because our focus was on helping people practice how to enter orders, we simplified our POS software to only include several core elements:

-- Product Categories
-- Products
-- Product Options
-- Checkout Options

We decided to leave some additional pieces in, such as discounts, order notes, and names for orders, if their implementation would be relatively simple.

After some initial sketches on a whiteboard, I used Photoshop to lay out what the game could look like and how players might enter orders:

This initial set of images helped guide a discussion between the developer and me (early on while prototyping we were the only two on the project). 

Together we thought up a potentially improved interface. It appears less visually cluttered, does a better job of only presenting information when it's relevant, and has more of a step-by-step, left-to-right flow to it:

I made a spreadsheet containing all of the categories, products, and product options and provided some placeholder art. I also provided a list of 100 names for the different customers. Then, after we defined some simple rules for what orders are made by customers, the developer quickly brought everything together and we had our first build!

With the first build we realized:

1. With a minor adjustment we could create an additional mode in which players can use the virtual POS on the tablet to roleplay and practice with another person. 

2. We need to include actual customers

3. We need to let players know what they missed

4. We should think about sound sooner rather than later...

The first item in the above list led us to an obvious question to be answered, "How does the person pretending to be the customer know what they can order?" I put together the following menu for the game that could be printed out and given to customers. This solution seemed clunky but worked well enough for now.

The second item (we need to include customers) led to questions related to the level of control and interactivity we wanted to provide players. I created another set of images to explore an idea in which players would be given two views, one of the virtual tablet on the counter and one of the customer. 

I thought that this would reduce friction related to players being overwhelmed by controls, prevent our team from grappling with first person mobile controls and its implications, and possibly capture the feeling of taking orders by restricting what players are able to do depending on what their camera is focused on.

When it came to feedback we still weren't sure which parts of the experience would resonate most with players and what information would matter, so we limited our work on this until we were able to get the game playtested. In hindsight, I'm not sure that this was a good idea (more on this later).

It can't be overstated how important sound is to an experience. In the past, I had neglected this insight and so wanted to start thinking about this element as early as possible.

I found an assortment of Creative Commons sounds and music (I already had some tracks in mind) and added them to a game recording in Adobe Premiere.

I named the files and handed them off to the developer. Even in their raw, placeholder form they added so much to the game.

The developer also implemented a text-to-speech solution to add a much-needed listening element to the order-taking process.

📂Link to audio concept 🎥

With the core of the game in place and tested in-studio for usability, it was decided that we would do an art pass before the game's first public playtest. The art team swiftly generated a style and assets to match.

We had our first playtest build ready to go:

This build was played by over twenty people belonging to the intended audience. Of these I personally observed 13 players.

I created documents for people to enter their observations, organized the results, and generated another document in which results were ordered based on their frequency. This document was then used during playtest results discussions in which we would determine the impact of each result and how to address it.

Here's the primary information that we collected:

• Asking a customer for a name for the order is confusing, both in that it needs to be done at all and how to do it.

• The text-to-speech is funny, especially when combined with some of the customer names that were included.

• Feedback from the game about how you did is not obvious.

• The 'Required' and 'Optional' screens can be confusing if they're empty.

• Players enjoyed commenting on the customers. Some even started to make up stories about who the customers are.

• Some of the fictional product names are confusing.

• Some orders (especially coffee orders) are confusing because customers can ask for contradictory options.

• It's not clear to players that they can edit items that have already been added to the cart.

• Some players had experience working as a cashier and said that the register in the game was similar to what they used.

• The experience was relatively easy for most players to understand. It seemed to be too simple in some ways and few players chose to play again when given the option to.

Due to various circumstances and studio goals, this project was put on hold at this point. However, we felt confident after watching so many people play that its core interaction was viable.

After the project was picked back up for further development I got to work articulating and illustrating the types of changes we could make based on the playtests. The producer and I generated a sheet to prioritize the things we had in mind and with the rest of the team we assessed if and how they could be implemented.

The first things that I helped think about were the potential changes to be made to the virtual point of sale software. We wanted to create an interface that enabled players to more quickly and easily understand what they were presently doing and what they could do based on where they were in the interface.

I wrote up a document containing all of the potential changes and made a series of images that showed the 'before' and 'after'. This documentation served as a way for all of us to be able to clearly discuss the ideas and generate feedback about them.

Next we wanted to communicate more clearly to players how well they were completing orders. I thought it would be effective and fun to show players how their actions were affecting the customers. This was primarily based on players' enjoyment of the customers in the playtests. It also gives players a chance to empathize with their virtual customers in some way which is a valuable skill for any customer-facing position.

I put together two concepts illustrating how a customer might react when having their desires fulfilled or their hearts broken (think about how great it can feel to get that one thing you absolutely want from a café!).

Another action item for us to work toward was providing some context for players and a smoother entry into the experience.

I created a concept using images from Pexels for a simple introduction that told players who they are, where they are, and what they're doing.

I then played with the idea of a menu that used the game's primary interaction. This fits the theme of the experience, could potentially serve as a "soft" tutorial, and uses assets that we had already made.

I tried to tease some ideas to the team about more modes and settings, but we ultimately decided not to take on too much for this iteration.

The second playtest build didn't come out exactly as planned due to some unforeseen issues, but we included the changes that we wanted to test in some form (and more).

Regardless, we had our first attempt at a more robust feedback system in place and believed it was more than far enough along to provide us with the observations we would need to get the project into a release-viable state.

Work on the project was put on hold as the studio worked on various projects. During this time however, the second viable build ended up being used in surprising ways that generated the feedback we would need to complete the project.

Here were the primary changes that I was tasked with that we wanted to make and test prior to release:

• Find a way to present players with how they did that enables them to more quickly compare the customer's order to what was entered

• Reenable multiplayer mode

• Explore options that can lead to more natural-sounding customers

It turned out that the feedback screen didn't work. People didn't understand what the hearts were meant to represent nor did they feel compelled to take a second look at the comparison table.

The initial concepts depended on showing the customers receiving their order and reacting to the situation and then forcing them to open a more detailed review of the results in order to progress. Showing players what happened like this probably would have resulted in players more clearly understanding how they did. But, I had incrementally made changes to a design without testing it and because I did so gradually, I failed to see the missing parts and gaps in the design.

The subject matter expert on the team gave us an idea that fit the theme well and fit new needs that popped up in the project, that if the order results were presented on receipts?

I got to work generating some ideas:

After reviewing these with the team, we realized that I needed to put together a concept that automatically presented both the original customer order and what players entered:

We thought this was a strong layout to try.

However, there's a lot of information to present to the player. We needed to make sure that it could be followed easily. Additionally, this new item-to-item layout led to questions around how to present missing and extra items.

At this time the team happened to start using Miro so I decided to explore different layouts there. The most helpful aspect of doing so was how much easier it became to compare different groups of concepts together in real time with remote team members.

I think it also has potential as a more dynamic and collaborative design document (something I've been experimenting with in more recent projects). 

After reviewing these ideas as a team we found the following layout
most clearly communicated the results to the player:

Unfortunately at this point we ran into numerous issues trying to update the UI again (the dev taught me a new vocabulary term, "tech debt". So, in order to meet our deadline we regrouped and he made some last minute magic happen to create a layout that still presents all of the necessary information:

One of the last major things that I contributed to the project was an update to the in-game café menu. The menu for Bean's Cinema and Café had only received minor changes since the very first prototype.

The imaginary store was originally imagined as a snack stand with a few extra options. To add a feeling of a complex coffee order I included numerous options for coffees such as non-dairy cream, sugar substitute, and flavor shots. However, due to shifting priorities we never decided to address some of the more interesting orders that would result from the way orders were generated:

To try to address this without needing to update any code I removed some of the extra options and reframed the flavored drinks as entirely new separate products.

So instead of a customer ordering a Small coffee with hazelnut they would now order a small hazelnut Bean Milk (Bean Milk is the cafe's version of a latte and came about as a fun solution to the fact that the text to speech struggled to pronounce latte consistently!).

When the new items were coupled with additional work that the developer implemented to add variations to ordering language we were pleased with how effective the results were given how relatively little complexity and effort were required:

At this point production ended and time was needed to refine and implement Simcoach Games' proprietary software. Aside from providing additional testing as needed, my role in the project came to an end.

After several stops and starts (and many builds later) we finally saw On Register debut on the app store.

Here's the final result:

• There's an opportunity to modify the experience so that the player progresses in a more interesting way. In its current state this is closer to a training tool than a game. This is fine for specific uses but limits its ability to maintain engagement outside of those instances.

• Players seem to have the most fun with the customers who come up to the counter. I would love to explore that more by giving them more personality.

• We definitely needed to playtest earlier on in the project.

• There's an opportunity to explore more cashier-related responsibilities. During development I made several concepts related to branching dialogue, handling cash, and building the customer's order (several of which resulted in prototypes and even an additional app). 

Back to top (Reloads the page)

HOME

RESUME

ABOUT


CONTACT

blagania@gmail.com
LinkedIn