We’ve all been there…looking at a product that isn’t quite perfect, trying to decide whether it’s time to release & iterate, or, timelines and budget permitting, holding off until a few more kinks are ironed out.

It can be a tough feeling releasing a v1 that comes up well shy of the long-term product vision you’ve been imagining. But we all know the value of iteration: “release early, release often,” goes the adage. You’ve got to get that real-world data to obtain the best blueprint for your needs moving forward. 

While we, by and large, stand behind this conventional wisdom, there are also some occupational hazards with the early-release model. The most common thing we see organizations run into is pressure to add more and more features with each sprint cycle following the v1 release, prioritizing these more exciting additions over less jazzy (but crucial) investment in the design’s infrastructure. They’re pushed to release something with serious experiential flaws they intend to resolve later on, but those UI fixes keep getting bumped down the list in favor of the shiny new thing that makes for a better press release or sells a new client. Over time, this adding and adding onto the flawed core infrastructure makes it extremely hard (and costly) to make those initial design fixes. Essentially, everything is balanced on a shaky foundation. They know they need an overhaul, but it’s only getting more daunting as time goes on.

This is design debt. And if it sounds familiar, you aren’t the only one.

We’re all sometimes forced to make tough product decisions, making tradeoffs with hard-to-anticipate implications. Figuring out what can and can’t wait, especially when it comes to less sexy usability features, is inherently difficult. We empathize with organizations in a sprint-based world, increasingly pressured to do more with less. If this is you, read on for our tips on navigating this environment while avoiding the kind of design debt that could put your product, or even business, at risk.

Tip 1: Include a fixed phase within your initial scope

Despite knowing that there’s always a need for a course correction after launch, it’s all too common to neglect including a “fix phase” into the initial project plan. This can turn even the smallest, most high-impact tweaks into a hindrance no one has budgeted the time or money for, and lead to the accumulation of design debt down the road. 

Simply budgeting a week of post-launch problem-resolution time into the initial project plan will do a great deal to mediate this. Making corrections will feel like an expectation rather than an unwelcome surprise, and the most critical, infrastructure-related issues can be solved before more features are stitched into a framework that will need to change. You can also use that bug-resolution time to socialize the live product. 

(Sidenote: it may be worth planning more than a week if you’re releasing something particularly new and unprecedented. And you may be able to get away with less time if you’re releasing something that’s more like a new flavor of something tried and true.)

Tip 2: Make sure you know which features will impress the stakeholders

The goal of every v1 release is different. Sometimes, it’s simply about gathering initial user feedback that will inform v2. Other times, it’s also important to impress important stakeholders — it may be the leverage point that’s needed to gain an investor, inspire some good press, or convince a key prospect to implement at their organization. 

All of which is to say: it’s often the case that you need to think about more than just user needs with a feature set…you also need to think of who needs to be sold in order to get the funding to make it to v2. While an inspiring, detailed vision presentation can be helpful, there’s no getting around the fact that you’re most judged on what is. If your v1 doesn’t adequately help stakeholders see value in the vision, it may stall out before you can build on it. In addition to addressing the non-negotiable core user needs, it may also be a smart investment to build out a taste of something flashier and future-minded to help people see, tangibly, where you’re going and buy-in. 

Tip 3: Don’t expect infinite patience from your users

Of course, it’s not just investors and strategic partners who will judge you based on what is — it’s also the users. Sometimes, an exciting-enough MVP can generate patience from your user base to resolve bugs and usability glitches along the way. But if you wait too long to fix their pain points, they’re at risk of finding some other way to address their need, forgetting about you, and not coming back. 

It can help to stay in touch with end users about bug fixes and feature enhancements, but even the best expectation management in the world can’t negate the need for quick fixes, especially if your product is being used in a high-stakes industry. 

Tip 4: Keep a detailed backlog, and share it widely

Another all-too-common way to accumulate design debt is by simply not appropriately logging all the intended fixes and enhancements to a product. Without good documentation of what needs work, you risk not taking full advantage of resources when you finally get the time to make improvements. Product development is a fast-paced world, and even fixes that feel completely unforgettable can get lost amid a new wave that requires your attention and focus. 

A robustly detailed backlog may be one of those less exciting, dot-the-i-cross-the-t project steps — but it pays off. We recommend logging not just the fixes/enhancements, but also including a good deal of detail about what the fix would involve resource-wise, projected impact, and how this fix relates to anything else on the backlog (e.g. would implementing one fix change the resources/impact for another? could efficiencies be created by combining fixes? etc). 

Once you have the backlog, it’s just as important to make sure everyone stays in the loop about it — your stakeholders, your users, and, critically, members of your own team. Folks who’ve been working hard for the release will typically be invested in its success. They’ll be helpful contributors to the backlog, and they’ll also benefit from the transparency of seeing when (and why) features important to them are liable to be addressed.

At Grand Studio, we specialize in helping organizations prioritize their product roadmap in a way that considers both their current resources and their longevity. 

Want to learn how to prevent design debt, or mitigate the debt you already have?  We’d love to hear from you. 

Are there any issues with translating my voice skill into another language?

Creating voice integrations for large companies with diverse user groups who speak different languages usually means having a conversation about translation. It’s so tempting to take a design created in one language and directly translate it into another language for deployment. Often, well-intentioned arguments about creating consistency for users regardless of their language come into play. To create that consistency, though, we actually can’t do a direct translation. But why not? Why can’t we simply translate one conversation into another?

Semantics

The most obvious reason we can’t just do something like a Google translation on a VUI design is that the specific words you use and the order in which you use them may not translate. Meaning, you can’t do direct one-to-one translation because it will sound like a foreign tourist asking you how to ride the bus to a popular sightseeing destination. It just sounds…off. The whole point of our latest voice platforms and designs is to create natural-sounding conversations that easily engage people without asking them to do mental gymnastics to figure out how to get their tasks completed. When you have an out-of-the-ordinary sentence structure or phrasing, it creates a heavier cognitive load, and people’s brains have to work harder. (Think: “Where to find the library of the city of New York?”) Users already have to work harder in a voice interface than in a screen interface since they have to remember what’s being said as the device speaks to them. Don’t create an interaction that becomes a brain task and a memory game. People will abandon it — or get very frustrated if that interface is their only option.

Culture

So let’s say you address the semantics issue by hiring a translation plus interpretation service. Well done, but you may still need to consider culture. In certain cultures, even if they speak the same language, the culture may be different enough that it may be awkward or inappropriate to use a certain phrase — or even a certain voice — to deliver specific messaging. For example, Portugal’s Portuguese is very formal, and Brazil’s Portuguese is far more colloquial/casual. If you use a Portuguese interpreter/translator, it will be hard to capture the wordplay native to Brazilian Portuguese. If your voice application is meant to be playful, this may prove detrimental.

Likewise, if you are delivering sensitive or personal information (like health information) in a culturally-conservative country, you may have to record the information in either a gender-neutral voice or in male- and female-gendered voices in order to help users feel comfortable hearing it. Otherwise, you may run into issues of people getting offended or shutting off the voice interface because it feels invasive or uncomfortable to them.

Localization

Even if you don’t have to translate from one language to another, you may still need to take localization into account. Language is a reflection of the people within the community you’re speaking to, and inclusivity is part of what makes users continue a conversation. That means you have to contextualize the word choices your VUI speaks and understands to accommodate your users. Whether that means regional dialects or phrasings, or using “lift” in lieu of “elevator” in a UK-based app, it’s important to capture the way your users most commonly speak to make the conversation — and your app — as natural and comfortable as possible. Many companies are launching these conversational applications in order to create an easier interface for their users and build up a rapport they can’t create in a standalone GUI (graphic user interface). Don’t work against that by excluding people’s word choices.

One additional thought about localization and inclusion: much like racial and gender bias in machine learning, we cannot script North American-centric conversations and assume those apply across all cultures and peoples. Not only is that inaccurate and can cause a lack of adoption in particular instances, it’s also harmful to the overall adoption of voice interfaces and people’s enjoyment of them. People use the stuff they like. They talk to people they like. If we’re going to combine the talking and the stuff, it follows that we should make it something they like in order to continue the use of them. Assuming that people either think like you or they’re not worth speaking to is not a good way to get them to like your stuff or your product.

Help from non-VUI team members

By this point, I can imagine you may be thinking, “sure, great, but I don’t have an arsenal of resources at my disposal to do this the ‘right’ way, so I’ll have to do it the realistic way instead.” I get it. It’s not always possible to have a staff of people native to English and the language of choice for your application on your specific team.

But even finding other non-designers or developers to help you test your VUIs is helpful. It makes designing and testing in those languages so much easier to do the same internal prototype and QA testing when you have someone who understands the nuances of both language and social scenarios of conversation to move through the conversation and ensure it feels right as well as is accurate to the original intent. There are even some online tools out there that can allow you to usability test for cheap with people in the language you’re choosing.

What if you have to release a less-than-ideal translation?

We’ve all been there. The timing, the resources, something happens that means a less-than-ideal translation is going to market. In some cases, it may be better than forcing someone who doesn’t speak English to struggle through an interface in a non-native language. But consider the blowback that may occur of providing an excellent experience in one language and a subpar experience in another. You may get away with it for a little bit, or you may not.

One band-aid you can try, if you have to release an imperfect translation, is to acknowledge the imperfection with a line in your greeting. You can try something like, “I’m not the best Tagalog speaker, so bear with me.” Or perhaps you can connect to a human resource to help through crucial moments — IVRs often use this trick. Though, if all your human resources only speak one language, absolutely make sure you let the user know the language will change before handing them off to the human. (I can’t tell you how jarring it is to go through a Spanish-language IVR and be passed off to an English-speaking representative without any advance notice.)

Point being…

Whatever you do, know that conversation is a reflection of the people you’re speaking with, and the same detail and care you pay to craft the conversation in one language should be translated to the next.

Want to learn how Grand Studio can help your next VUI design project and build clarity out of complexity?

We’re here to help!