Part Two | More Techniques to minimize the Jank and elevate your experience
VR, AR and MR have become the new showcase for jank of all types. It's so frequent and widespread that expecting some janky aspects has just become the norm for immersive spatial experiences. XR users and developers seem to have accepted that it's something to be expected, something practically inevitable. And yet it's rarely viewed within development as something that can be factored into development planning or that might be considered during initial ideation and design.
This always seems crazy to me, as there are decisions developers make at every step of their development cycle that can significantly affect the chances of janky aspects ending up in their final build.
Previously on...
Last time we talked about what 'Jank' actually was and how it can manifest in an XR context, looked at some examples of how Jank can appear as a by-product of aiming for a deeply realistic simulation-based implementation of interactions and mechanics, and why emulating an interaction is more important than simulating one when it comes to immersive experiences - and how doing so can save you time and effort. Let's carry on looking at more ways we can design and build towards smooth usability, and avoid the disappointments of janky moments and interactions blighting your finished experience. Avoiding XR jank should be an important consideration throughout every step of development.
What to know about avoiding XR Jank and achieving 'Smooth Usability' in your Apps and Games | cont...
5. You can (and should!) accommodate known and expected user needs
There are some elements of almost any VR, MR or AR experience that you can easily predict will benefit the most from having some extra time and resources dedicated to them; they're deserving of extra and particular attention.
Many of them are things that every user of your software will encounter while using it, and so obviously these are high value areas for you to focus on, ripe for imbuing a sense of quality, finish and -- yes -- smooth usability into your game or app.
A few of them are areas that are sometimes treated as an afterthought by developers, but which can be constant touch points for your users during their actual time in your virtual world. It’s easy to forget that users aren’t aggregating and totalizing all the jank in the app the same way that someone with a developer’s purview might; they’re running into that jank whenever they run into it, every time it happens. So figure out where your users are really spending their time, and make sure the portions of your app that they encounter most frequently are high on your agenda.
All of them are worth serious consideration as places you might want to spend extra time and effort if you’re looking to raise the overall sense of quality, usability, and care that your experience communicates to your users.
The list below is not prioritized, because every game and app would have different features with different priorities, but they’re all features that can be important to get right if you want to make the best impression and avoid that sense of jankiness.
My recommendation would be to rank these features in relation to your specific user journey(s), and the likelihood and regularity of any given user encountering them.
(a) Pause / resume
Think how many times you pause a game during the course of play. Think how many times you visit the settings screen in an App. It’s a lot. Sometimes it’s to change a setting – but sometimes it’s just because you have to take a comfort break, need to answer the door or want to check your phone. These screens are an escape and a refuge as much as they are a utility, and this is doubly so with XR mediums where the intensity of the experience can be greater, and the need to tailor the settings to your personal preferences is more likely. If there’s a better candidate for the best place to apply polish and do something unique and memorable, I can’t think of one.
Examples | Horizon: Call of the Mountain and Vertigo 2 pause the action and blur the immersive world away to keep you immersed, but offer respite, settings, and important information. Synapse offers a chill, dark space to catch your breath and check your abilities, away from the frantic action of it's psychic gun-play.
There are plenty of VR apps that miss an easy win by having standard pancake-style pause screens, offering all the utility but none of the razzle dazzle that makes a great impression that sticks, but two solid recommends in this department are Synapse from nDreams and Asgard’s Wrath II from Sanzaru. Both are well worth taking a look at for maintaining a great sense of immersion, providing a respite from the main game, offering up some other stuff for the user to focus on for a minute or two, and giving off the sweet aroma of polished quality. Your users may spend more time here than you'd imagine, so it can be a great place to invest extra polish time. And even if time is tight, it's a vital area to prioritize for de-janking.
Recognize that any issues users encounter elsewhere in your app or game, they may well come here as their first stop to find a way to fix it. In that way, it's like the customer help page for any other app or service - and we all know how frustrating those can be when they're not designed customer-first. These days, showing that you care and that you genuinely want to help your users has becoming an increasingly unusual thing, so care spent here can truly elevate your experience in a user's eyes.
(b) Comfort Options
More than any other medium, we rely on a rapport of total trust with our users. We ask users to blindfold themselves, shut themselves away from the world they are familiar with, and then place their trust in our software to lead them safely through a new, unfamiliar world whose properties, rules and experiences are entirely at the creator’s whim.
This creates a new and entirely unique relationship between the content and the audience, requiring an unusually responsible and understanding approach from creators. Beyond just providing entertainment or utility, your experience has to act as host, guide, teacher and carer for your users. That latter aspect means It’s up to you to offer all the safety and comfort they might be seeking, ready for them at the moment they need it. Comfort options should be clearly explained before they’re activated – don’t make it a necessity for your users to try them out to understand what they do, and what issues they might help with. If they’re seeking comfort options because they’re starting to feel squiffy, that’s the last thing they need.
Being able to smoothly navigate to find the right help when you need it is a perfect example of the smooth usability ideal you should be aiming for. And every user inevitably ends up here to tailor their preferences for locomotion and navigation at some point, making this an ideal place to be making a good impression.
If you want to dig a little deeper into this important area -- and you should! -- make sure to check out our eBook VR Discomfort - A Guide for Content Creators if you haven’t already!
(c) Catering to common Fears and Phobias
This is an accessibility consideration that’s becoming increasingly popular in traditional flat games and apps -- thank goodness -- but it’s always been of major significance for XR mediums where we’re either putting users into surreal VR worlds which might contain acute triggers for the many fears and phobias we collectively carry as humans, or to bring those things into our real world spaces, like AR/MR.
In a survey of 22 countries, 7.4% of respondents reported that they experienced specific phobias within their lifetime, and 5.5% of respondents had a specific phobia within the last 12 months. (Journal of Psychiatric Research, 2020).
Here in the UK alone, around 10 million people suffer with at least one phobia. They can affect anyone, regardless of age, sex and social background, although some specific phobias will affect women more than men, and some are more common in higher income communities.
All of which is to say that, as host, guide, teacher and carer for your users this is the sort of area that developers do have responsibility over, and the power and tools to address them. It may not qualify as 'jank' in the strictest sense, perhaps, but it can be a showstopper for your customers. Acknowledging these fears, and providing a way to keep going if your application contains elements that may be triggering for some users, will be a seen as a very positive usability step. At the very least, you should remember that it's your responsibility to warn them in advance, ideally before the point of no return -- whether that’s in the store listing, at the checkout, or before you let them put on the headset at a live event or out-of-home experience.
There are solutions to deal with many of the most regularly encountered triggers, and because it’s a new area for users where there’s a need and desire to tailor their experience to their specific preferences, it does make sense to cater to as many of these as you can, and as you see as appropriate.
It's obvious when your main content elements are going to be triggers for some people, but it's important to consider the moments you deliver and the assets you use to do it can be nasty surprises for some users. Triggering an anxiety or phobia unexpectedly will make affected users lose a lot of trust in the title - if this happened when they weren't expecting it, will it happen again? And in the long term, that can mean wariness about future works from your studio, and possibly negative reviews and word of mouth.
Better to establish trust with them before they encounter the triggering content by showing your consideration, even if that amounts to an asset-swap solution that looks jankier, or a 'skip' option that breaks your finely crafted experience and makes them miss some of your content. You don't have to spoil the surprises for everyone - have a discrete phobias/triggers menu with a content spoiler warning on the outside. It’s always pleasing to me to see apps and games that are sensitive to common phobias and allow users to, say, swap out spider enemies for something less triggering. There might be a creative regret in allowing a dramatic climb over a vertiginous drop to be skippable, or swapping out creepy, skittering spiders for generic smoothly rolling balls that don't mimic spiders in any way, but users will appreciate the option, and it’s a strong cue for non-sufferers that you’re a very user-forward developer who actually cares - and that might lead to positive socials, and a loyal fanbase moving forward.
It’s not just fear of spiders and heights of course -- you'd be surprised how deeply some phobias, fears and anxieties can be felt in our immersive mediums, and it's not uncommon for users to be exposed to new experiences that they've never encountered in real life before, and discovering all-new things that some of them might find bothersome.
Here’s a list of some of the common fears, phobias and anxieties that you might encounter in an immersive game or app --
Arachnophobia | An intense fear of spiders and other arachnids |
Ophidiophobia | Snakes, why did it have to be snakes? |
Acrophobia | An intense fear of heights, and falling off them |
Aerophobia | An intense fear of flying |
Cynophobia | An intense fear of dogs |
Astraphobia | An intense fear of thunder and lightning |
Trypanophobia | An intense fear of injections and needles |
Coulrophobia | An intense fear of clowns |
Social phobia | Social interaction anxiety, may be triggered by NPC avatars as well as human-controlled avatars |
Entamaphobia | Fear of doors - often around closed doors or locked doors |
Claustrophobia | An intense fear of small, closed spaces |
Agoraphobia | Fear of places that are difficult to escape, including crowded and/or open spaces |
Kenophobia | An intense fear of the void, the ‘fear of the empty’ |
Nyctophobia | an intense fear of darkness and/or night time |
Aquaphobia | An intense fear of water |
Autophobia | An intense fear of being alone |
An interesting app to keep an eye out for in this space is Nope Challenge which features a great example of a pause / options screen that focuses on being a literal escape from their phobia-based bravery tests, accessed by the user hitting the titular big red ‘Nope!’ button on their wrist. Once there, it’s a menu screen presented a relaxing chill-out zone with pleasant diversions, as covered above, mechanically necessary and thematically perfect for the game’s whole approach.
A great tip is to give users an option to report moments when something is creeping them out, sending back a snapshot image and their game-state data. This is especially useful during your early testing, and any open alpha/beta builds you share out. But leave it in your final release - for affected end users it's better than nothing, and you can learn from it as developers. Include a dedicated form on your website that invites your users thoughts and requests, and point users to it from inside the app. It will be a source of high value data for you internally that can afford you deep insights, and the very presence and accessibility of such a system is going to up your ‘smooth usability’ ranking with users.
And as a new area of accessibility, there’s value in establishing yourselves as an early leader in this space, too.
(d) Reset VR position
Obviously, the ‘VR Reset’ is a standardized function that users will rely on, and the major platforms do a great job of making the function easily accessible and understandable already. However, the behavior within your application in response is very much under your control. The standard out-of-the-box solutions should be seen as a starting point; they make assumptions that are great for a generic use case but may not be ideal for your own. Sometimes you'll need to think hard about your user's behavior, and why they might be taking the time to reset their position at any given moment.
To give you an example, the developers of the fascinating VR climbing game Bean Stalker must have faced a significant challenge with their title, which allows players to climb-like-Jack to the top of immense, twisting beanstalks using a pair of climbing claws and a grappling hook. Along the way they'll be facing wasps, spiders and all sorts of other oversized terrors who are intent on making you fall to the bottom - a fate that comes all too easily, making you start your climb again. Players crawl around every side, walking on top, climbing along the sides, hanging beneath the stalks, weaving around the organic shapes to find the safest route, stay out of sight of enemies, and explore the many surprises they find along the way.
Using quantized (snap) turning to rotate in 30º chunks as part of this free movement is fairly unwieldy, so playing by physically turning your body around turns out to be pretty much essential. As players climb around and reposition themselves for safety, they physically roam all over their play space, so for some users there's a constant need to keep moving back to the center point and resetting their VR position and orientation. The bigger the playspace, the less likely this is to happen, but if you're immersed for long enough it's easy to wander away from your real life center. Imagine a scenario where you're hanging by hooks 500 feet up, you've been climbing for 10 or 15 minutes and you've backed yourself into the corner of your real life play space. The user will try to keep their grips tight so they don't fall off, return to their playspace center, and probably turn themselves to a particular orientation to help reset their internal compass, before they press the button to reset their positions and recenter the game. It can prove endlessly problematic to actually play for long periods - sooner or later the reset system, as robust as it has become since the original release, will make an incorrect assumption about what the user is intending to achieve, and you'll end up with your avatar stuck inside the beanstalk neck-deep, or detaching one of your claws during the transition, and plummeting to your doom.
Bean Stalker | VR Storm
I don't envy the team at VR Storm who faced an impossible task and did an amazing job regardless, but there still remains plenty of weird edge cases for many users where this real-world play space issue effectively sabotages the game. Progress is frantic and hard fought, and the penalty of falling is significant both mechanically (ready to try that climb again, Jack, but harder now because you've less time and less health items remaining?) and also in terms of the toll it takes on the player's patience and engagement. Despite all the challenges the devs have solved, there's a constant expectation for the player that sooner or later a janky reset might derail the time invested in a whole session. For all the multi-use weapons and clever tools the game allows a user to sling over their shoulder or strap to their torso to take with them up the beanstalk, there isn't a tool that solves this particular issue.
I certainly don't mean to dunk on the team or the game here - but it's a useful example to cite of an independent title that literally reaches for the sky, but fails to join the gods because an occasional moment of Jank - not Jack! - can bring the whole thing crashing down. Had the team fully appreciated how hard this might be from early on, they might have modified their ambitions and built for shorter, quicker, or less perilous ascents that had less chance of frustrating their users. Maybe they could have adjusted their goals for the free climbing feature perhaps, and avoided some of the issues that way? It's impossible to know. Over time the game has been updated and revised to address some of the issues, but the fixes never fully let the ambition of the game manifest as intended. Don't get me wrong, it's a hugely appealing game with a killer core concept, and these days it's in the best shape it's ever been and certainly has it's fans. But I suspect it's failed to find the audience it might have, and is burdened with an unshakeable reputation now forever more of being 'a janky VR game'. It strikes me that the underlying design, which gets so many complex things right so much of the time, depends so heavily on the need for completely reliable behavior, and assumptions about the position of the user's torso. Even if you solve for 99% of instances, the timing of a single janky moment can ruin all goodwill. Half a mile up in the air, you're relying on those behaviors to work as you expect, 100% of the time.
Another example is still an all-too-common user issue that you've probably encountered yourselves; sometimes apps will reset the user’s position correctly, but fail to properly reset their orientation. While this should be straightforward, it can get complicated by the user's posture and mobility - sitting, standing or room-scale - that have different requirements. Sometimes users change posture -- they'll go sit down wherever their chair is and expect to carry on seamlessly from there. In other cases apps will snapshot the user's orientation at a certain point - say, before it throws up a loading screen - and use that as the forward vector to show the image, text, loading meter, hint popups and so on -- but they do this at a moment in time when the user has been looking at a black screen for 5 seconds and is probably just starting to look around to see if they're missing something, and thus misinterprets which way the seated user is actually facing. If they don't check that look-vector again during loading then the user is frustratingly saddled with a ‘forward’ direction that isn't forward. I've even seen this affect full-length intro cinematics that go on for minutes, and if you can't swivel your seat, you're craning to watch and then starting the experience with a crick in your neck already.
Apps make assumptions for the sake of convenience, but sometimes those well-meaning assumptions manifest as significant jank when the user can’t wrangle them to their needs.
(e) Dominant Hand
In Western countries, left-handed users are a minority at about 10-15% of people, but it should be no surprise to XR developers that lefties deserve love just as much as the majority righties. But XR apps, and especially games, sometimes present poorly for those users.
I have a decades-long background in videogame development, and I know that the developers of a game or app will spend a lot of time getting the controls assigned correctly and fully finessed - after all those are important points in communicating game-feel, and we want to thin out the membrane between the real and the virtual - the controls are the point where our user directly touches the world on the other side of the screen. But I also know that on some titles I've been involved with, broader accessibility testing hasn't been done until late in development, and some of these dominant hand issues have proven to be harmful late distractions when they've emerged late in the development cycle.
There’s a long-standing ‘wisdom’ that all left-handed user need is a simple control mirroring, but that would also include swapping the controls assigned to the thumbsticks –- which can be a massive and unexpected discomfort trigger for many users -- and not something we should be expecting the user themselves to simply adjust to. Imagine a VR flight sim where the virtual throttle control is near your left leg ... or ... you can also use the right stick. Or an ammo clip that goes in one side of a weapon but has it's button flipped confusingly to the opposite controller. These sort of things happen, and when they don't get corrected their approaches can be inadvertently aped by the next developer and become entrenched.
Our ‘smooth usability’ ethos means we should properly think this through and test with plenty of left-handed users and take their advice on board. It's easy to look at other apps and copy them, but it's also easy to make assumptions about what others might want, so go right to the source as often as you can. Lefties aren't hard to find.
The ideal is to make all hand interactions ambidextrous, so either hand is capable of the same interactions. This sounds straightforward, but be aware that emulating a real-world interaction from the perspective of both left- and right-hand dominance is trickier than you might think. Because you're trying to meet expectations, you need to understand the intuitive feeling the user is expecting, and some interactions -- pushing a lever to the left vs pulling a lever to the left for example -- can require discretely different approaches to fully emulate the expected sensations. So, again, test with users with different hand dominance whenever you can.
If you can’t make all your interactions ambidextrous, the next best choice may be to offer assignable controls. Failing that, at least offer multiple control schemes to select from. Ideally you want your users to make the choice before the first moment of unexpected discomfort is triggered. An age-old videogame trick that can work here is to figure out which stick the user prefers by asking them to, say, push forward to move, and seeing which stick they do this on. But don’t stop your accessibility considerations there; make sure things like attach points and holsters are considered alongside this, and even things like the hand-outlines on hand scanners and so on.
Electable options and good communication are the keys to smooth usability here, and will get you love from both lefties and righties alike. And these schemas, once designed and implemented, should be a solid platform that every future title you develop can iterate and build on. Getting this stuff right and listening to your users is high value in terms of giving your app that sheen of polish and consideration.
(f) Eye Dominance and visibility considerations
In much the same way, Eye Dominance can also be a consideration. The XR community is still largely built on the shoulders of traditional flat screen 'pancake' applications - and has inherited pancake sensibilities when it comes to making use of 'screen space'. In a 2D videogame, for example, we'll tuck information, scores, meters and quest information in all four corners of the screen - and this works great, and developers have become deeply knowledgeable about the most effective placement and presentation for different types of game-critical information.
Spatially, though, we don't have the idea of 'screen corners', of course. Some apps will recreate the traditional flat screen layout by using head-locked (or head-trailing) information and panels, creating a non-diegetic 'layer-zero' upon which that same game information -scores, readouts, maps and so on- is presented front-and-center by keeping the information locked to the user's head (look-at) vector, rather than attaching it to the world. Conceptually this can work, if done well, but in practice a lot of implementations overlook an obvious difference, and for some users this can render the app difficult -- if not impossible -- to use.
This 'zero layer' is stretched across the user's vision, in much the same way it would be stretched across a TV or monitor screen. But we can look at a TV or monitor, close one eye, and still take in the whole screen. Most people don't have 20/20 vision without eyeglasses or contact lenses. One estimate suggests that only about 35% of all adults in the U.S. have 20/20 vision without corrective lenses. We're not yet at a point with XR where the hardware always accommodates glasses wearers, and even when there's enough clearance space for spectacles and headset lenses to avoid avoid the risks of clashing together, it comes at the cost of reduced field of view, and those preferring larger spectacle frames might still struggle to fit them within the device's eyebox.
So it's safe to assume that some of your users will be using the headset with compromised vision in one or both eyes. There's not a lot you can do about that, but you can make sure that any critical info can still be comfortable viewed with either eye. It's an easy test - just keep one eye closed and make sure you can still see everything you need to and can still fully use the app or play the game.
I've got very poor stereo vision, my left eye sees the world as a blur and so I'm very right-eye dominant. But it does mean that I spot lots of issues when I'm in-headset. The most egregious (and common) issue I run into is floating bubbles of text that stray to one eye or the other, or head-locked UI elements that I can't ever bring into the right side of my vision. Information panels positioned spatially on my left need me to twist my head and torso more to bring them into view, and my instinct is to use stick turning for this - which usually rotates the panel as well, and I endlessly spin like a dog chasing it's tail. One skydiving experience I tried recently had a heads-up display on the left side of the helmet visor that I just couldn't read at all. They might be cool and immersive for users without my poor eyesight, but for me it's just another janky aspect that I can't do anything about, and which can render otherwise great experiences into frustrating guessing games.
Considering that other users out there can and will have different and unique issues, it's good practice to avoid head-locked or head-trailing UI elements if at all possible, and if it's not (such as a helmet-locked heads-up display), then being able to customize the layout, or select from different options, will be appreciated greatly by those affected. It's only a little more work to keep the layout flexible, and it can help some of your users immensely. It's also easier than trying to design a one-size-fits-all solution that actually will fit all.
(g) Teach and Try-outs – On-boarding and Reinforcement
On-boarding is a whole subject area unto itself, and we don't want to get too sidelined here, but one thing I have noticed is that jank often shows itself first in the onboarding portions of an App or Game. Titles that are otherwise well polished and smooth to use can often stumble with janky tutorials, misleading examples and confusing instructions.
The reasons why aren't that mysterious. Tutorials are naturally put together towards the end of development when every system and function are finalized and locked, and it becomes safe to figure out the what and how of the Tutorials without the danger of constant rework. It's already a lot of work for content that the user will (hopefully) only need to run through once, and both developers and users want to get it out of the way as quickly as possible anyway so they can get on with the experience itself. And then add to this the difficulty of actually creating an effective and engaging tutorial where the lessons are learned and the info retained by the user. It's easy to see how, even with a healthy block of development time allocated, the onboarding can be a late victim of emergent jank and inadequate testing.
But reasons don't matter to the end user. This is their first point of contact with your creation, and that means those first impressions are being made right there and then. Teams will put a lot of effort into their first chapters (see 'Put the effort where it will be encountered, and choose your battles wisely' in Part 1 for more on why) and tune and user-test them to maximize their impact and give an amazing opening chapter experience. But they don't always manage to lavish the same amount of attention on their tutorials and onboarding. It might only come into being at the close of development, but you should be considering your onboarding approach from the earliest possible point in development. Videogames now commonly adapt a tutorial structure which bends the narrative to it's needs; there's a reason so many games start with a boot camp or cast the player character as a rookie on their first day on the job. Apps have a harder time, often needing more up-front teaching time for an often disparate collection of utilities which can often see them splitting their onboarding effort between in-app guided tours and tutorials, and out-of-app videos and articles.
Also consider this: It's not unusual for users to go long periods without revisiting your app or game. This is an area that's severely under-serviced in both pancake 2D and Immersive formats. There's few games, for example, that will take the trouble to provide a 'Previously on...' service to remind players exactly what was happening in the narrative, and what they were in the middle of doing, when they last played the game 12 months ago or however long it might have been. There are few apps that are helpful enough to see you haven't used them in a while, and that you might like them to flash up a quick summary of the stuff you used to remember instinctively. As someone who swaps between multiple creative apps all the time, and generally flits from game to game, this is something I really appreciate in the odd instances where developers have been thoughtful in providing it. Most interfaces are similar between products, but not identical, and the differences trip you up. Clever and unique features and mechanics benefit from these things the most. I returned to Red Matter 2 after about a year's absence and was stuck for 3 sessions trying everything and backtracking everywhere to solve the puzzle I had encountered before I parked it, something that required me to plug in a connection interface that pulled out of the side of my virtual hand - a cool VR thing I had forgotten all about, and not something you'd think to check for! But as far as I knew until I eventually caved and watched a stream, I had encountered some weird bug preventing progress, and the game was just broken.
Not too long ago I helped a developer with a great app that some users are finding fairly inaccessible. The reason for this is because of an obligatory tutorial which, while comprehensive, unfortunately doesn't account for users running around like kids in a schoolyard, messing with all the activities in the world and triggering the tutorial stages out of order. Some users join the dots in the right order and have a great experience, but there are enough users having issues that it was being reflected in the user reviews, and the accordant review scores. It's a shame that such a strong and generally polished underlying experience had been hidden behind a fog of confusion and jank for some players. And as is often the case, the cause of this was a noble and well-intentioned one, with the devs just wanting to allow the users freedom to explore and interact with the virtual world from the off. It's always a noble and positive aim, but one that, as many developers learn, can go awry in the execution and miss it's target. It happens, of course - but the important step the developer took was recognizing there were issues, and then bringing in help to identify what the causes were, and to figure out what actions were needed to get them addressed most efficiently and effectively.
Often bringing in independent new users on your project can be illuminating. Encountering your experience as a fresh new user and charged with giving honest feedback, they can uncover all sorts of niggles and issues that you, as developers, can become blind to, or have mentally (or perhaps even officially, on a production chart somewhere) pushed down the priority list for perfectly sensible reasons. But as I always say; making games is hard. Building Apps is hard. And when you're putting users into your game or app to encounter to experience them as an intimate connection between themselves and the software, it's incredibly hard. So getting experienced eyes on your Game or App can be incredibly helpful in identifying important areas to focus on.
Few experiences are 100% jank-free, but there are plenty of titles out there that feel like they're punching above their weight in terms of quality and polish, and in terms of the overall positive user experience they manage to deliver. At the same time, they exist in a sea of titles that sometimes come tantalizingly close, and those with great ideas that do amazing things nobody else had thought to do -- but which just had too much friction, too many hiccups, too much jank to really nail that long-term relationship with their users. All the time, effort, love and money that those developers invested in those projects, the big dreams and even bigger hopes that they had for their immersive experiences -- it can all be undone if the experience isn't smooth enough and intuitive enough for users to stick around. Word of mouth can now be global and instant, and disgruntled customers can turn loud and antagonistic. The combination can be punishing for developers. The VR market is mature enough at this point that appearing jank-free out of the gate has become increasingly important for early reviews -- and reviews can make or break the fortunes of VR titles both small and large.
So don't settle for just accepting janky areas of your implementation that functionally work, but give the user an awkward, unintuitive or problematic experience. A user issue is essentially a problem with not understanding what any given user expects. So bring in help; bring in your friends and family. Bring in lefties and righties. Bring in the tall and small, young and old. Ask them what they think. Make sure they're all feeling the same delight in your interfaces that you designed them to deliver. Make sure their personal user journeys don't get tripped up or blocked by janky elements that you just don't encounter when you work through the app yourself. While some of them will walk the path that you intended, plenty of them will do surprising and unexpected things and wander into areas you don't expect them to go. Every user, as we always say, is different.
And if you think you need to, bring in an expert (hello there!) who can help you make the right choices to achieve a feeling of smooth usability in your experience, to help you identify areas of jankiness you might have missed, and to help you focus your efforts in the right places to elevate the overall quality of your immersive experience in everybody's eyes.
Comments