As someone who loves video games, I believe that there's a lot of inspiration that mobile & web designers can draw from game interactions. After all, using a joystick on a controller is not very different than swiping a screen with your thumb.
One such design that I've often been intrigued by is called a Radial Menu. While radial menus are more common in video games, we rarely see them in mobile or web designs. I wanted to show that Radial Menus can translate to other platforms, so I've set out to prove it with a few designs of my own.
Rather than listing menu options in a single column, the radial menu angles the options out from a center point on the screen. This means that all of the menu options are a single interaction away from the user's starting point. Instead of scrolling through a column of options, they simply need to flick the joystick (or thumb/mouse) towards their desired option and they'll have achieved their goal.
Radial menus are great for quickly navigating through a set of common interactions in a user journey. It's often easier to recall the angle of a gesture than it is to anticipate the exact point on the screen that a desired option will appear, so once a user is familiar with an interaction they should be able to navigate a flow without even waiting for the menu open.
Outside of video games, this works best on touch-based systems because as soon as the user sets their finger down they've created a focal point for the radial menu to expand from.
Radial menus are not universally appropriate. It's inherently more difficult to read a list of options when they're not aligned to one another, and if there's a complex hierarchy of sub-options then it could be challenging to display those to a user.
Additionally, swiping interactions are less accurate with a mouse than they are with a thumb or joystick, so the advantages of making quick, angular gestures might not translate to a computer terminal.
Radial Menus are best used for common interactions on mobile devices that users will want to do quickly, and repeatedly.
Using an app to navigate a real-world space runs the risk of creating unnecessary pain points. The goal is to keep the relevant information front and center, so that the user can engage with their surroundings and not their phones.
With Curate, I kept this problem front-of-mind as I developed my designs, and a Radial Menu seemed like the perfect solution.
My original wireframes called for a more traditional hamburger menu, but after testing with users I realized that all options were already included in the top and bottom navigation bars, and therefore redundant.
The disadvantage of removing the hamburger menu was that the sub-tabs of the Explore page (Art, Tours, Events, and Services) could only be found by navigating to that page. If a user wanted to find a restroom, they would first have to navigate to the Explore - Art tab, then change to the Explore - Services tab, and only then could they find the restrooms.
To speed up the process, I decided to include a Radial Menu that will expand when a user holds the "Explore" button on the homepage. If the user clicks the button without holding it, they will simply be navigated to the default "Explore - Art" tab.
In my second round of User Testing I found that user's weren't familiar enough with the Radial Menu enough to use it efficiently. This was expected. After all, if RM's were widespread then there would be no need for this test case.
However, some users did find it to be an interesting feature. The motion design of a rotating radial menu provided an engaging experience, and those who did comment on it were either positive or curious, while none were negative.
Still, I found that the overall lack of familiarity with the app itself didn't allow users to take full advantage of the design. Users never really made it past the learning curve, and as such it was difficult to judge whether or not the Radial Menu was a success, or merely an interesting feature.
My user testing with Curate showed promise, but in order to continue exploring the value of Radial Menus I knew that I would have to get feedback using an app that people were already familiar with.
It just so happens that I was already experiencing a pain point with a very popular app that sees repeated daily usage: Instagram. I determined that a Radial Menu redesign would be the perfect opportunity to solve it.
When I first attempted to add something to my "Story" on Instagram I found that the process was far less intuitive than one would expect for such a critical action on the platform. The "Add" button is small, and placed in an out-of-the-way location on the page.
Once clicked, it defaults to adding a "Post" (I'll refrain from suggesting a change to the default content-type, since that decision should rely heavily on data that only Instagram has access to). The User then encounters an interface issue with a visually indistinct overlay sitting on top of the photo gallery as the only way to change which type of content the user is submits. It took me several minutes to notice this overlay the first time I tried to add a Story.
My hypothesis is that a Radial Menu can improve this process by speeding up the interaction for frequent users, while also creating a more visually distinct Call-to-Action that draws the user's attention to this app-critical function.
My first design challenge was in finding space for a radial menu within the existing app screen. In order to maximize the benefit, I wanted to make a much larger "Add" button that was easy to reach with a right-handed user's thumb. This would ensure that swiping through the menu was ergonomic for most users. However, Instagram's bottom tab bar was already full with five icons, so I swapped the locations of the "Profile" icon with the "Add" icon, and increased the size of the Add Icon to make it more visible. This had the added benefit of moving the profile to the top-right of the screen which is more consistent with other apps.
I also wanted to ensure that the visual and motion design were both consistent with Instagram branding, and engaging to the user. A colorful circular frame helps to provide contrast against whatever posts are displayed in the background, and having the icons expand from behind the Add button signals an equal hierarchy across all of the different post-types, as opposed to choosing one as the default.
This interactive prototype gives the full experience of what a Radial Menu could feel like on Instagram's platform. Try adding a Story, a Post, or both! If you're an Instagram user, test how it compares to your experience with Instagram's current UX.
I believe that this is a great example of how a Radial Menu can benefit Mobile interaction designs. With a simple swipe, the user can bypass a default option to achieve their end goal. They don't even need to wait for the animation to complete in order to perform their desired interaction. And if they haven't yet learned which direction to swipe in, they are still presented with a full menu that intuitively teaches them how to swipe in the future.
I have yet to conduct extensive User Testing with this prototype, although I would recommend performing an A/B test alongside the existing interaction to see which performed better. If my hypothesis is correct, I would expect that the Radial Menu will delight users and encourage them to create even more content for the platform.
This entire project has been an exploration into a design choice that I thought was interesting. And as I wrap things up, I remain convinced that there is a place for Radial Menus in Mobile interaction design.
While its implementation should not be universal, the Radial Menu is most effective at making repetitive interactions faster by allowing the user to skip 'default' pages and go straight to their intended goal. The sacrifice is a more traditional Linear Menu, which clearly states page hierarchy to the user and is almost universally understood. Of course, being unique is not necessarily a bad thing, particularly if the above principles are applied.
Regardless, I would recommend plenty of user testing to any organization before implementing a design such as this. While the potential for a great user interaction is there, success really depends on the context in which it is implemented.