The better the research, the better your plan. Combining the hard-and-fast numbers-driven data points of quantitative research with the broader “why” and “how” questions of qualitative research sets you up to make well-informed decisions that truly speak to the problem at hand. 

That said, to some, qualitative research can feel squishy and daunting. Protocols as rigid as a survey will prevent truly illuminating findings from surfacing, but also, going in with too loose a plan can lead to time-wasting or significant gaps in findings. 

At Grand Studio, answering juicy qualitative research questions is among our favorite things to do. We start by working with clients to understand the decisions they’re trying to make, then co-craft a plan to help answer those questions. While every research plan is uniquely informed by the context and questions surrounding it, we have a few best practices to share. 

Best Practice #1: (Really, Really) Know Your Research Questions

We know this one sounds obvious, but this is a common problem we run into with clients. They’ll have a general sense of what they want to learn about but haven’t yet distilled these into concrete research questions that can keep teams on track in the field. 

Stakeholders who’ve been steeped in a problem for some time can probably rattle off the most critical research questions on the fly. But when they aren’t concretized into a clear list, things can get lost in translation when more people get involved. Researchers constantly encounter twists and turns out in the wild, and their clear understanding of the research goals can be the difference between a smart on-the-fly adjustment and a wasted day. 

We’ve also seen situations where the research goals are made clear at one point, but as folks get wrapped up in the work and adapt to surprises, the initial need can get lost in the mix. As pedantic as it may be, we recommend putting the research questions at the center of every research check-in and synthesis meeting. “How are we progressing along our goal of learning X, Y, and Z?” Impossibly simple, but the benefit cannot be overstated. 

Best Practice #2: Be Wary of Shortcuts

Life gets busy, and shortcuts can be tempting, especially when your research questions are so vast. Every day, there is slick new technology released, promising to enhance and streamline your qualitative research. We’ve looked at every piece of technology that’s come our way and tried out a lot of the new tools, Ray-Ban Stories and dScout’s diary study tools. While some are helpful augmentation tools, nothing we’ve found is a viable replacement for on-the-ground research. 

The bread and butter of qualitative research is talking to humans, and there’s a reason for that. No matter how crunched your timeline, be suspicious of things that try to steer you away from that. 

Best Practice #3: Choose Your Methodology Wisely

There is an art to choosing a research methodology that is nearly as critical as identifying your research questions. Once you’ve got a clear understanding of what you want to learn, you need to figure out the best way to learn it, and with whom. Say, for example, you’re doing a study on how people make decisions while grocery shopping. An interview may be able to tell you general things about how people shop. But when you’re on the ground, observing or doing shop-along, you’ll get so many details people would never have thought to tell you in an interview. Plus, the way people explain the why and how of what they did in the past can often be very different from what they say in the moment.

Perhaps the most tricky part of this is responding to inevitable restrictions that come up. Usually, there will be at least one or two feasibility or legal concerns that keep you from using your “dream” population. This requires you to get creative about how you can optimally answer your research questions using the tools you have. You don’t have to be in an exact real-life situation to get highly usable data.

One last point on methodology is to consider the reciprocity of the research. Sometimes, research questions may be sensitive, or catch people in a difficult moment in their lives. You don’t want to skip these perspectives, but you do want to be sensitive to them. For example, at one point, we collaborated with a client on a project to better serve the needs of cancer patients. With their support, we set up a table where patients could get free warm socks in exchange for their thoughts. 

Best Practice #4: Go Wide, Wider Than You Think

One of our favorite parts of qualitative research is the surprise involved in answering such large-scale questions. But it’s also the trickiest because, by nature, one cannot entirely plan for surprises.

Knowing that, at the beginning of the research, you don’t know what you don’t know, we recommend casting a wide net. Talk to more types of people and roles than you think you need, especially if these people are easy to access. You don’t need to go overboard — just one or two sessions with a new type of participant can do the trick. We’ve made critical discoveries by taking the time to talk to someone slightly adjacent to the primary field of research who ended up having a great deal of insight into it. Go small at first, just to see if there are new stones worth turning over. 

Best Practice #5: Always Stay Aware of Bias in Synthesis

There is no way around the fact that humans are biased, even researchers who try very hard to be objective. 

We’ve found that the best way to introduce objectivity is not to push individual brains into objectivity, but to stack many ideas on top of one another. Try to use at least a few researchers, and gather their own unique perspectives on what they are seeing. Ideally, people from your organization should also review their findings and point out their own conclusions. Individually, no one’s perspective is objective. But when we see which trends emerge collectively, it’s more likely that they’ll be rooted in the actual research.

As is often the case with hard things, they frequently turn out to be the most worthwhile. Don’t be tempted to skip qualitative research if it sounds time-consuming, just make sure the research plan is well-matched to your timeline and budget. And, of course, we’re always here to help.

Got a qualitative research project you’d like to work together on? We’d love to hear from you.

While every environment is unique in its own way, healthcare might take the cake when it comes to a need for specialized design considerations. 

There’s a trifecta of challenges: legal requirements to contend with, complex funding pathways, and the fact that what’s at stake might be life or death. How do you build technology poised to make a meaningful difference without endangering what’s already working? 

Grand Studio had the privilege of working alongside several clients on the front lines of healthcare and learned a few lessons.

Find a sustainable funding source, and check the CPT codes

With the interplay of public payers, private payers, and providers, the flow of funding in healthcare can be complicated. Whenever possible, aligning your intervention with a CPT billing code can be a smart way to position your technology of sustainable financing.

In the past several years, there have been more and more codes released that allow providers to bill insurance companies for digital health interventions like remote patient monitoring and patient engagement, and still, more are on the way. It’s a win-win-win for all involved: providers get reimbursed for investing in technology that improves health outcomes, patients get more tools that help them get and stay well, and the insurance companies spend less on patients who need less care.

Once you’ve found CPT codes that may be applicable, dig into the specific requirements to ensure your technology can meet them, and — critically — make sure your technology is designed to facilitate easy billing. 

While recently working with one of the largest US private healthcare systems, we co-designed an intervention for pregnant people with pre-eclampsia. We created a digital triage system to catch early signs of a problem, improving patient safety and staving off costly ED visits. While the avoidance of an ED visit was a saving unto itself for the healthcare system (and for the patient), we also designed the program to align with the CPT code’s billing requirement, which stated that providers could only bill for the remote monitoring if they saw the data and acted on it. As designers, this kind of requirement is frustrating in how much it limits the service experience. We saw enormous opportunities for automated alerts and interventions. Still, it was critical for us to remember that the service could not be funded and, therefore, couldn’t exist if it did not live within the payer requirements defined by CMS. Understanding our real-world limitations allowed us to build something viable and desirable.  

When patients are involved, study their mindsets carefully

We are perpetually in favor of doing robust research on end users, and healthcare is no exception. 

Whether leaving the hospital, adjusting to a new diagnosis, or even coming in for a check-up, people’s experiences in and around a doctor’s office can be highly emotionally charged. You may be dealing with people who are exhausted, people who are sick, people who are nervous about their loved ones, people who are confused but afraid to tell their doctor or people who can’t process any information at all because they are still in shock. Standard “design conventions” that may work in other environments could crumble in healthcare if they don’t address the specific emotional valence of the patient experience.

For instance, we once worked with a nonprofit health system to redesign how cancer patients checked into the hospital. In most contexts, efficiency is priority number one — the fastest solution is the best solution. In this setting, however, it was also essential to prioritize the slower face-to-face interactions that let these patients feel like humans, not numbers being churned through a system. Moments of warmth and connection were precious for people dealing with the magnitude of doctor’s appointments that come with a cancer diagnosis. (It’s worth mentioning that helping people feel more connected to their healthcare providers doesn’t just make them feel better — it can improve health.)

Understanding the patient’s mindset is also crucial when your goal is health behavior change. As healthcare providers know all too well, simply having the solution to a healthcare problem doesn’t mean it will be solved. Patients often do not follow their provider’s recommendations to take their medications or implement a lifestyle change. It usually isn’t because they don’t want to — it’s simply because there are too many barriers. Often, these barriers are emotional. It requires thorough research to stand a chance at cracking the code on what actually moves the needle on patient behavior. 

Despite the challenges of healthcare, it’s a gratifying field to work in, and we’re eager to collaborate with more clients trying to support people where it matters most.

Got a healthcare technology project you’d like to work together on? We’d love to hear from you.

Reworking a process that’s been around for a while can feel like opening Pandora’s box. 

Especially at large organizations, the prospect of reworking something that involves so many people is intimidating. And it’s not just the price tag — the prospect of making a significant change at an established organization usually requires near-herculean efforts of diplomacy and buy-in. 

With all that stacked against leadership, it’s no wonder any process working at least well enough stays in place as long as it does.

You may wonder how you got by when you finally cross the bridge to the other side. If done right, a service redesign has the power to revolutionize your organization, allowing the breathing room that lets people work and imagine to the best of their capacity. Job satisfaction goes up, and the bottom line does, too. 

If the light convinces you at the end of the tunnel, but you need help figuring out where to start, read on for our take on three common barriers to starting. 

Barrier 1: Too many politics involved in implementing a change

With more prominent organizations especially, decision-making is often dispersed across a number of groups, only some of which may talk to one another. The urgent problems of one faction of the company may not even cross the radar of another. The prospect of making a change with all those moving cogs can feel daunting to the point of impossible. 

Our best tip here is to get “in the room” with folks (even if it’s a remote room). It isn’t about turning on the charm to win someone over. It’s about demonstrating a genuine commitment to understanding their work and what’s important to them and creating improvements in a way that respects their lives and expertise. The sheer fact of feeling seen can do wonders. What shows up as stubbornness often belies a strong emotional connection and care about their work, which is grounds to connect. Plus, you may learn something that helps inform your approach to the redesign.

Tip: While this will seem biased, hiring consultants for some of this early diplomacy can be a game-changer if you have the budget. In addition to approaching the problems with fresh eyes, outsiders can often leverage an apolitical status and sense of urgency (due to budgets and timelines) to cut through entrenched political issues that can be very difficult to resolve from the inside. 

Barrier 2: Something feels wrong, but you’re not sure what the problem is

This is another common problem — our clients may have a general sense that something is inefficient but not know how and why it originates. 

We also sometimes see the flip side of this — clients who can pinpoint the issue precisely, but once solved, they realize it’s a symptom of the problem and not the core cause. 

For this, the best first step is to simply get out into the field. Watch people work, ask them questions about why they do what they do, and understand what motivates the different actions you’re seeing. While it may sometimes be daunting getting the logistics and approvals to go on-site, there is usually no faster way to diagnose the “real” problem than by getting into the thick of it.

Case study: With a recent healthcare client, we went out into the field expecting to streamline a patient registration process through digital tools. But after being on-site, we realized that solving the registration problem would actually create a new problem: when patients got to interact with an employee, even in an inefficient way, it let them feel known, cared about, and human. The problem to solve wasn’t digitizing clunky in-person processes. It was about optimizing moments of human contact.

Bonus: Having tangible examples to share with other groups can help lead to better communication and common ground for moving forward.

Barrier 3: The problem feels so overwhelming, you don’t know where to start

Start paralysis is one of the biggest barriers we’ve seen clients run into. Particularly when you are embedded into the organization you’re trying to change, with an up-close view of all the interconnections, interdependencies, moving parts, and potential obstacles, the prospect of getting started can feel like setting off a domino chain of chaos. There’s fear that change may actually make things worse.

In a perfect world, maybe it’d be possible to step back and assess your organization thoroughly and objectively, making a perfect step-by-step map of the best order of operations in which to tackle the overhaul. But in reality, it simply doesn’t work that way. 

One of the most significant steps toward success is letting go of the idea of starting in the perfect place and simply starting somewhere. After all, there’s nothing like getting into it to help you refine your map for the next journey phase. Indeed, the time will come when you need to coordinate efforts across the board, but having everything mapped out before the first step begins is an impractical goal that can stop efforts in their tracks. 

Tip: Experience and intimate knowledge of an operation are invaluable, but when it comes to getting started, it can also be a burden. Often, our clients know too much about what’s going wrong and can get into paralysis in figuring out an excellent place to start. Here is where outside eyes can be beneficial in helping you find a suitable starting place.

In sum, there’s a light at the end of the tunnel, and we hope to see you there.

Got a service design project you’d like to work together on? We’d love to hear from you.

It’s 2023. Most of the low-hanging digital transformation fruit has been picked. We’ve got online shopping, digital media, and online scheduling systems…while we’d hesitate to call any digital transformation “easy,” the more straightforward projects have already been crossed off the list.

What we’re left with now are the harder-to-budge changes. We’ve got industries like finance, healthcare, and manufacturing that, in addition to being strapped by complex laws, are also highly human-dependent. Digital transformation isn’t a simple 1:1 switch, putting an e-widget where a physical one used to be. To pull off a genuine digital transformation in industries like these, you often need to change the whole system to some degree. And we don’t need to tell you that such a thing can be extremely challenging.

In our experience, coming up with the actual solutions our clients need is usually the relatively easy part. Very few needs are entirely unprecedented, and Grand Studio has been in the game long enough to spot patterns in what tends to work. But, as we know, simply dropping even the slickest of digital tools into an institution not yet ready to adopt it is an effort destined to fail. The hard part — what we spend a lot of time thinking about as a design consultancy — is how to get people to buy into digital transformation.

Here are a few buy-in barriers we’ve run into, and how to navigate (or, better yet, prevent) them.

Barrier 1: People feel a solution is being pushed onto them from above.

Any digital tool should always be framed as operating in service of people — not the other way around. Unfortunately, however, many people have been forced to work with tools that feel more like a chore than a service, and that suspicion can carry over to any new digital product. We like to address this explicitly when we do research, framing the job of the tool as directly supporting their work and existing routines. We ask lots of questions about their needs and habits and make sure that these are respected to the degree possible in the final design. If we’re working on revamping a system that is currently painful, it can also help to acknowledge the frustrations they’ve been dealing with. It builds faith you’re setting out to do it differently this time.

Barrier 2: People fear being replaced by digital tools. 

This fear has been around since the very first digital tools surfaced, and as technology advances, it’s not going away anytime soon. Workers who have specific technical skills, either resulting from formal education or on-the-job experience, will be justifiably proud of their abilities and defensive about new technologies that could displace them. However, we’ve hardly run into situations when a digital transformation is designed for, or results in massive layoffs. Usually, the organization’s goal is to optimize, get more results out of the resources and employees they have, and allow humans to work at the top of their skill level. If this reflects your organization’s strategy, it may be wise to address this concern head-on, mediating any fear about how roles may change once the new process/product is implemented. 

Situation 3: Highly technical audiences do not trust something digital to do parts of their job.

Related to the fear of being replaced is the suspicion that nothing digital will be a viable substitute for a person’s expertise. We see this in many types of industries, and it’s a difficult hurdle to overcome. We find that significantly involving these technical experts in the process is the most powerful way to confront this resistance. 

Initially, you’ll want to do extensive research with them, understanding the ins and outs of their jobs and expertise. Next, budget some time for these experts to test the tool out before widespread release. In addition to likely making your product better, this allows some time for folks to develop trust that the tool can be relied upon. We’ve even seen some stakeholders gain excitement at this phase, seeing how delegating some of the simpler parts of their job can enable them to work faster and better — it’s often the case that the bits best suited to new technology are the bits users currently hate to do, and that makes for a powerful case for change. Your pool of collaborator experts will do the job of spreading the word to other experts, and when they do, they’ll encounter much less suspicion than an outsider would.

Situation 4: The prospect of change in any form feels overwhelming.

No matter how well planned, change is often hard. One way we like to work with organizations overwhelmed by change is to start small. Even if your digital transformation goals are mighty, beginning with one bite-sized, concrete thing people can use immediately will do two critical things: first, build trust that you can deliver on your project goals, and second, demonstrate to others how change can happen. Quick wins build the faith you need to get those larger projects rolling.

We love working with clients on the precipice of a digital transformation. Have a project you’d like to work together on? We’d love to hear from you.

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!

Tackling a big refresh on a product that’s been around for ages is a huge undertaking. In addition to the redesign work, there’s usually a drawn-out diplomacy effort in getting buy-in, organizing the project, and socializing the change. And while most redesigns have popular support or they wouldn’t get the go-ahead, it doesn’t mean that a project won’t have detractors, skeptics, or folks displeased by  the disruptions it generates. Navigating all this requires significant attention and communication, the upshot being that the work — as is often the case with these large-scale efforts — goes far beyond the work itself. 

At Grand Studio, we’ve had the privilege of working with many clients as they tackle big redesigns. Because we know how much legwork it takes, we’re always looking for ways to help our clients economize their efforts and generate bonus benefits from the work  they’re already doing. If you’re on the brink of a big redesign, read on for a few tips on getting more bang for your buck. 

Strategy 1: Leverage the redesign to boost or repair reputation

Many teams, often through no fault of their own, are tasked with managing old tools and products that — to put it delicately — are a little suboptimal on the usability front. This can generate significant reputational damage for the team at the helm. Of course, no one enjoys being on the receiving end of negativity, but this bad reputation also represents a degradation of trust that makes it tangibly harder to get things done within the organization. A product refresh can be a great opportunity to mitigate this reputational harm and put a better foot forward.

For instance, we recently worked with a large medical technology client to refresh an internal purchasing tool that had been causing strain on thousands of employees for years. As part of the redesign, we reached out directly to those most adversely impacted by the tool’s shortcomings. In addition to providing a wealth of information about improvement opportunities, we used these conversations to validate frustrations, provide context on the barriers that had prevented earlier improvements, and demonstrate expertise and commitment to work towards something better. This kind of work helps us to understand how to improve the product while demonstrating a commitment to making our users’ lives better.  

Strategy 2: Be proactive about change management

Even if the redesign ultimately makes everyone’s life easier, change can nonetheless be tricky. This is especially true if your process involves temporary product outages, significant process changes, or a steep learning curve. As such, it can be extremely helpful to communicate proactively and robustly with teams who will be impacted by the redesign, bringing them along with you in the redesign versus simply sending out an FYI when the switch-over happens. 

As in the prior strategy, taking the time to understand a redesign’s implications on various teams and workflows positions you to strengthen the product and build trust and goodwill. Some clients we’ve worked with tell us that the positive communication streams established during a redesign have provided lasting benefits to their organization, impacting projects far beyond the initial collaboration. As designers/researchers, we’re also on the lookout for data communication streams that should stay open past the initial engagement. For example, any metrics we look into for the purpose of the research will likely be incredibly useful mechanisms to measure how a project is doing on an ongoing basis.

Strategy 3: Evaluate the cost/benefits of bringing features in house 

Especially when your organization is just starting off in a new domain, it can really kick-start things to partner with third parties on technology. Instead of taking months to build something in-house, you buy something ready-made and take it for a spin. However, if this third-party tool winds up becoming a big part of your business, there may come a time when it makes more sense to bring it in-house. While the up-front cost of doing so will usually be large, it can de-risk your business from relying too much on third parties, allow you the flexibility to custom-build the product to your exact specifications, and often save you money in the long run.

If your organization has green-lit a design overhaul, it usually means there’s popular support for the product’s utility as a core part of your business. Accordingly, it can be a good time to assess the business case for bringing any related third-party tools in-house. 

Strategy 4: Incorporate forward-thinking process changes

Sometimes, the best time to throw in change is right on top of more change. While it may seem like a terrible idea to incorporate large-scale process changes into a massive redesign, we’ve found that, in most circumstances, the opposite is true.

During a redesign, people’s mindsets are often more expansive, and their ideas are more malleable. As such, it can actually be a prime opportunity to shake up stagnant processes and try out a new way of doing things. Chalk it up to redesign the procedure and test out the new processes you’ve been meaning to socialize, whether it’s a prototyping workshop, a new stream of meetings, or a feedback touchpoint you’ve always thought should exist.

This is particularly likely to be successful if part of your work involves consultants or outside teams — people expect an even higher degree of change when there are newcomers around, especially those acting in a consultative capacity. Loop your consultants into any process changes you feel need to happen so they can support you in advocating for them.

Strategy 5: Take a broad view of KPIs

While you’ll keep your eye on the primary KPIs driving the redesign, there are often secondary or tertiary ways the redesign will have an advantageous effect on the organization. Getting a handle on what these are can add positive internal PR to your project, yielding increased buy-in for this effort and anything else that comes out of your team in the future. 

For example, we once helped a client redesign a tool that was massively confusing users, leading to errors that needed to be found and corrected downstream. Rectifying this user confusion was the primary goal of the project. However, as we got to know the space better, we saw many confused users call an internal support line for help, which cost the client resources.

We talked to the support center to better understand the questions and complaints they received related to the tool, and the redesign subsequently decreased their call volume. Decreasing support call volume wasn’t a main KPI, but it was an extremely welcome bonus outcome that made the project team look better. The more of these side stories you can gather while working on the project, the more your positive PR will disperse, generating buy-in and trust for this project and your next.  

For all the work involved in a redesign, it’s worth the effort to get the maximum benefit possible. For many of those benefits, attending to the softer/more relational side of the work gets added benefits for years. 

As a design and strategy consultancy, Grand Studio specializes in projects that involve not just doing the work but collaborating with you on high-level strategic thinking that can spur positive change within your organization. We know how to use our position as outsiders to support you in diffusing tension, breaking through ossified processes, forming positive new relationships, and workshopping fresh perspectives on chronic problems. 

Have a project you’d like to work together on? We’d love to hear from you.