.gif){kind=spacer}
Kickback is a 2D metaverse app. You can simply move around and talk to others in a way that feels less confined than a zoom meeting.
During the quarantine of 2021, I found myself having a lot more time than normal, so I went about trying to solve what I saw as one of the most annoying problems at the time, zoom meetings.
I entered a hackathon with this idea, and ended up getting 1st place.
After, I founded a startup and we brought this idea to life.
A bit into the quarantine, I found this hackathon with $10,000 in prizes, and thought the idea I was working on was a perfect fit, so I put together a team, and after several days of sleepless nights and non-stop work, we submitted the following video which won us the competition:
Create a way for users to freely move in and out of conversations.
I came up with the UI of kickback by building around two main core concepts
This interaction mimics how people talk in real life. It is basically a birds eye view of the real world.
This allows people to create groups of conversation on the fly, without managing who is in a room and who is not.
Before I came up with with any more thought out designs, all of this begin with one initial hypothesis, that smaller video has big advantages over large format video.
After raising a bit of money, we were off to the races to build out our product. We needed to simultaneously build and test. As you might notice, the product is no longer in existence.
One thing that we learned was picking the right tech stack early on is important. We started off using the DOM to render all animations, and had the entire web app built out after 3 months. When we got our first customer, our demo failed during the first test run. That's when we realized that solution wasn't scalable to large groups, we then decided to remake the entire app using HTML canvas, which renders using the gpu instead of the cpu. We were pretty close to finishing that one, but ran out of funding and had to find other work.
Over the course of this project, I learned a great deal about what it takes to bring a web app to market from scratch.
Designer, Founder
May 2021 - December 2022
Figma, Webflow, Design Thinking Workshops
Based off of user testing, I found that there were some issues navigating a large area when your field of view is so small. These are solutions to solve this problem.
Wayfinders help you find your friends easily on a large canvas.
If friends are outside of the screen, you can click on the wayfinders to quickly jump next to them.
You can also message friends with your location. You can either click on the pop up message notification to go to location, or you can go to go into your inbox.
This feature lets users get a birds eye view of the room.
The next features I focused on were around enhancing the way users communicated on the platform.
With this feature, users can shout to the entire room so others can hear them even if they aren't touching bubbles.
You can even start shouting while in map view.
This feature let you zoom in the view like it is in zoom.
In order to host virtual workshops, I found that it was important to empower the host of the workshop with various tools to organize the participants.
Users can upload image of zones to put on the floor and run workshops like on the youtube show jubilee.
https://youtu.be/BpRKCvWxiJwIn jubilee videos, there are words written on the floor and the host asks a question, and the users stand on their answer. Often there are different things written on the floor depending on the video's subject.
https://youtu.be/SjFeW_y7NYk
Unlike real life, where changing the floor would take time, moderators of the rooms can change the zones on the floor by using the slides feature.
Each slide can also have a question posed at the top.
This lets hosts lead a group through a number of pre planned out activities.
If you watched the video, there were quite a bit of features, as we moved forward with the project, we started to narrow down the scope, as well as changed the color-scheme. This contained the features we needed for our MVP.
Part of my research was looking at every possible competitor to see which niche areas I could plan to take over. I did an extensive analysis of which platforms contain which features.
For creating a UI where your character can move around and talk to others on a 2d canvas, there are two main ways you can handle the navigation of your character within the 2d space.
Here are 2 main interactions I found:
In games like zelda, your character is not fixed and can move to the edges of the screen.
Pros:
- Assuming you don't have multiple rooms/tiles and just have one giant room, if there are other users, you can see everyone in the space you are in.
Cons:
- you have a limited space.
- The space is limited by the screen size you are on. Bigger screens can show more space. This means if you change the aspect ratio of the screen, you will have dead space.
In games like pokémon, the user is fixed in the center, and this lets you explore in an infinite canvas.
Pros:
- You can have an infinite space to move around in.
- Your screen size and aspect ratio are flexible because all it does in just narrows the field of view, but you can still navigate all the same.
Cons:
- You don't know who is off screen, without way finders or some sort of map showing locations of people.
Things become a bit more complicated when designing for this type of app when you take into consideration how you move, depending on what type of device you are using. On the examples above, it is simple because the gameboy has the direction pad. But in our modern day, we have desktop, tablet, mobile, and vr. Each has different input methods.
Let's consider this Zelda movement style in the context of mobile, how does one move around? If you swipe do they move one tile? Imagine how many swipes it would take to get to the other side of the map. You could have a virtual joystick, but that takes up space, and then the area of the screen that virtual joystick takes up space.
What if you have a swipe? that could be interesting, but in practice, it isn't that intuitive if the user is not fixed in the center of the screen.
I opted for this movement style where the user is fixed in the center, because on desktop you could move via asdf, or arrow keys, or dragging the background while your character remains in the center (you can experience this by testing the Figma prototype. On mobile, you can move by dragging the background, while you are fixed in the center. The advantage of this is you can move quickly and are not limited by the speed set by arrow keys. If you have a phone and you use the figma prototype, you can test this movement out.
The first step I posted a video of myself going over a screen recording of my figma design. Both of these posts received quite a bit of engagement, but these are only 2 of the successful ones out of the 10 other posts I made. Posting on reddit to get feedback is a numbers game.
I received about 200 comments from these posts, here are two examples:
In order to make it easy to sort through the data, I downloaded all of the comments from the posts in a csv format (a lot of googling) and then imported it into miro as a bunch of post-it notes.
I then had a bunch of unsorted feedbacks, so made categories, and skimmed them one by one, and sorted them.
For the purposes of planning out which features we needed to create, the product market fit and feature requests categories of feedback were extremely useful.
In this section, I created a bunch of potential feature categories and sorted the feedback once again. Throughout the project I added more features I came up with to this list.
I used the product market fit feedback to make 4 categories of potential target markets this product could add value too, and then I sorted all of the user suggested features, as well as the ones I added, into this venn diagram.
This step was extremely important, because it helped us identify which features in the center which added value to all the market segments.
We took these features it the center and then re-sorted those in the following steps.
To prioritize which features to develop first, I did a Bang-For-Your-Buck analysis of each of the features from the center of the venn diagram above.
As a designer, I knew my estimates of how much effort each feature would take to develop wouldn't be completely accurate, so I then sat down with my lead developer, and we re-evaluated each of them using my draft as a starting point. We also drew arrows to other features to signify development dependencies.
This gave us a birds eye view of which features we should tackle first. The top left of the diagram is the features that added the most value for the least amount of cost to develop.
We then re-sorted this view into the tidier cost/benefit analysis diagram.
This gave us a really clear view of our top priorities. We then took these and then added a timeline to these features in the form of a roadmap.
We then sat down again and decided which features should be created when.
Lastly, based on our roadmap, I created this wireframe, and this served as our north star during development.
This process I created gave my team the ability to give input in every step of the way, and gave my team the confidence that we covered all of our bases for possible directions we could go in, and that we chose the right path.
We built this mvp in Unity. This app could pretty much do everything we wanted feature wise, but because it was built in unity, it had one huge drawback, we couldn't make a web app that worked well in a browser. This experience could work well on a desktop app, but when it came to marketing the app, people are not as likely to try out an app if you need to download something, so we figured we would have to change course eventually to create something that could support web app functionality.
When it came to our first user test, people really liked the experience. They could all bunch up in one group and have a conversation, or they could split off from the main group and have their own private conversations effortlessly. At 8:23 seconds you can also see the map view in use.
Our second MVP was built by our second CTO and he built this using DOM rendering. The tech wasn't ideal and ultimately crashed when we did our first real world test. We knew for a fact at that point that dom rendering wasn't fast enough to support a multi user chat application with over 20 users.
This was our 3rd mvp build by our second developer, unfortunately, we ran into problems with the voice api that needed to be fixed before we could do a trial run with our first paid customer, and then we ran out of funding. But the multiplayer movement worked really well, and I'm extremely proud of what we built.
A bit into the quarantine, I found this hackathon with $10,000 in prizes, and thought the idea I was working on was a perfect fit, so I put together a team, and after several days of sleepless nights and non-stop work, we submitted the following video:
While this ...
