Initiatives are a big part of our work life here at Xmartlabs. From time to time, we’re encouraged to take a break from our normal work duties and dedicate some time to research, develop or study something that interests us, especially if it might have an impact on our community.

In this blog, we want to share with you the process of one of our latest initiatives: developing a tool to practice and train the Uruguayan Sign Language (or LSU, which stands for Lengua de Señas Uruguaya). Specifically, we’ll dive into the Research and Product Definition processes that the Design team carried out, and some of the challenges we faced along the way.

The beginning

While we may have come up with a more romantic way of telling how things started out, truth be told, the origin of this project is rather straightforward: our Machine Learning team developed the idea of an innovative ML product that involved the Uruguayan Sign Language. Soon after, knowing that what often seems simple might actually have deeper implications, they decided to involve our Design team.

The initial idea was simple: a person would signage to a camera, and by machine learning magic, the product would come up with a translation in Spanish. Right from the start, we knew this idea was not completely original, as we had already encountered many competitors at some stage when developing similar products. However, no one was doing it here in Uruguay (at least to the extent of our knowledge). Knowing that each country’s sign language is different, the idea was innovative and exciting enough for us, so we got to work.

Apart from some personal, brief experiences with sign language and the deaf community, we didn’t have much knowledge about this topic. This scenario was any designer’s dream: a big, empty canvas and the opportunity to conduct a research process that would introduce us to the problem and the people it affected. But where to begin?

I’m a firm believer that despite there being countless design methodologies out there, our first step - consciously or not - is usually a Brainstorming session. This allows us to sit down and identify what we think we already know, detect what we don’t, and finally, envision what we need to learn.

In our case, we came up with several previous cases, a few competitors and, most importantly, lots of questions. These questions quickly translated into action items, which became our very first roadmap. Yay! The first step was done: we identified all the puzzle pieces we were missing and came up with a rough idea of how to gather them.

Did we follow this roadmap in this exact order or even fully accomplish it? Spoiler alert: we didn't. And we believe that’s the kind of adaptability a design process should have, especially in its early stages. As much as we try to foreshadow how things will play out, we must always leave room for changes and re-adapt our process on the go. But for now, let’s focus on what we did to follow this roadmap.

First Stage: Getting to Know Our Users

Step 1. Desk Research

The first stop in our journey was conducting Desk Research.

While many different definitions can be found, essentially, Desk Research involves reviewing what other people have already done or investigated about the subject. Basically, it's anything you can do from your desk without being actively involved in the field (hence the name). We could think of this as the “Googling stage” for the millennials' sake.

The main benefit of Desk Research is that it enables us to start defining the problem and making well-informed decisions, without investing too many resources yet.

During our Desk Research, we mainly focused on exploring the Uruguayan Sign Language. From its own characteristics and peculiarities to the differences from other sign languages in the world.

We also focused on understanding the characteristics and needs of its main users: deaf people. This led us to discover a community that is actively involved in the matter, from deaf people and their families to interpreters and professionals who support this community from their areas of expertise.

At this point, we had already realized the complexity of developing the product we envisioned: from communication barriers with our main target to technical challenges in adapting the technology to such a unique language. Clearly, we needed to gain first-hand insights from people actively involved in the issue.

Step 2. User Interviews

Moving along with our roadmap, it was time for the user interviews.

In UX design user interviews are a qualitative research method where designers or researchers interact with users to gather insights and feedback on their experiences and needs related to a product or service. They aim to gain a deeper understanding of the user's perspectives, motivations, pain points, and behaviors.

Knowing that to interview deaf users ourselves we'd need to overcome the communicational barrier and have someone interpret for us, we decided first to interview people who were somehow related to the LSU, but who weren't deaf.

We scheduled two interviews: one with Sara, a recently-graduated LSU interpreter, and daughter of deaf parents, and another with Mauricio, who has a psychology degree and works as an academic investigator about the LSU.

Despite only conducting a pair of interviews, and not having directly interviewed our target user, these proved to be a great source of information and valuable insights. We confirmed many of our assumptions about the needs and pain points of deaf people, how it impacts their daily life, and how their community works in a rather closed way.

Also, the interviewees mentioned a few tools and resources already used by the community, which led us to our next step.

Step 3. Competitors Analysis

As we’ve mentioned before, we knew our idea wasn’t a trailblazer from the start. But what could we do differently from these competitors to add more value or better solve the problem?

To find out, we conducted a Competitors Analysis exercise. We selected some products with similar features and analyzed what they do, how they do it, and how well they satisfy their users’ needs.

The analysis showed that current competitors did not meet our users’ needs correctly, at least not how we intended to. Overall, their usability was not great and presented some core issues. Besides one case with a more recreational approach, none worked with the Uruguayan Sign Language.

Based on these findings, we could confirm there was an opportunity to create a product that addressed these unsatisfied needs and filled the gap in the market.

Conclusion of this stage

During the first stage of our project, we verified the Deaf community faces many challenges on a daily basis in terms of communicating and interacting with the rest of society. We also gained a better understanding of the Uruguayan Sign Language, its characteristics, and differences from a spoken language, like Spanish.

Some of our main outcomes were:

• The LSU is a relatively new language, estimated to have been around for 30 years. Despite its recent growth, there's still a lack of standardization of the language.
• The LSU is constantly evolving, as new signs are continuously being created to keep up with the changing world, including the advent of new words related to current events, such as the COVID-19 pandemic.
• The language is abstract, iconic, and non-verbal, making it difficult to translate literally.
• Sign language involves the use of hand gestures, head movements, facial expressions, and eye contact. Each word is represented by a single gesture.
• Interpretation of the LSU is not a direct word-for-word translation, as the interpreter reinterprets the message's concept to be transmitted.

• In Uruguay, there are approximately 120,000 people with hearing problems and over 30,000 with severe or total deafness¹. Despite its size, the Deaf community in Uruguay is relatively closed due to factors such as communication barriers and discrimination issues.
• There is a large difference in the level of knowledge of LSU among generations, even within small age differences. For example, someone in their 30s may be highly proficient in LSU, while someone in their 50s may not.
• People who are deaf and interpreters connect and exchange information through online forums and Facebook groups, where they also reach consensus on new signs.

• Adaptability is a crucial aspect for sign language interpreters. They must be able to adjust to various factors, including the sign language knowledge of the deaf person and their unique signs and expressions.
• Despite the importance of their role, sign language interpreters face various challenges, including the need for recognition for their role, paternalistic attitudes, and a lack of knowledge about the specific contexts they work in. They are often seen as being in charge of the deaf person, leading to their infantilization. To overcome these challenges, it's essential for sign language interpreters to study and be prepared for different technical terms and specific contexts, such as medical, legal, and academic.

Despite all these challenges, it was clearly demonstrated that the Deaf community and the use of LSU continue to evolve and grow, as they find ways to connect, share information, and improve their quality of life. This realization sparked our interest to do this a free, open-source project, accessible by the whole community. In doing so, we could contribute to spreading the LSU visibility and contribute to the knowledge of hundreds of interpreters.

We also recognized that for the MVP version of our product, it made sense to target mainly LSU interpreters. By narrowing our audience, we could smooth out the heterogeneity of LSU knowledge levels, as this group tends to share a common base of knowledge that we could build on.

But while this first stage was crucial in laying the theoretical foundation for the rest of our project, it also became clear that we needed better product definition. Of course, we designers could have started devising and defining the product ourselves, and to be honest, the result could have been good enough.

However, true to the ‘teamwork is the dream work’ motto, we couldn’t envision doing so without the technical input and expertise the ML developers had to give. In fact, it felt like a natural step to avoid redundancy and rework in the future.

To further strengthen our approach, we decided to bring in a fresh perspective by including team members who had not been involved in the initiative and had not been influenced by previous research. This would provide an unaltered, neutral view of the matter. And what framework lets us involve many different parts and result in one defined concept? You guessed it: a Lean Inception.

Lean Inception à la XL

Lean Inception is a widely covered topic, about which many people have already said many interesting things. So what can we add that’s new? Well, for starters, we did our very own version of a Lean Inception, adapting it to fit our resources and needs.

From Paulo Caroli’s (the Lean Inception creator) very own definition, it’s a process framed within a 5-day week of work. Each day is divided into two main sessions - morning and afternoon - with a small break in between (for coffee, small talks or just reconsidering why we agreed to participate in this). However, with all of us busy with our client’s projects, we needed to shorten the duration to just a few sessions scattered around a few weeks. Far from seeing it as an issue, we took this opportunity to summarize and do what was really important and beneficial for our process.

Our Lean Inception team was integrated by product designers, a visual designer, a communications manager, sales representatives, a project manager, Machine Learning developers, web developers, and mobile developers. As you can see, a very ranged group of individuals (and a cute dog - shoutout to Venus!) with many different perspectives.

Overall, we gathered for one kick-off session and then three different work sessions. During the kick-off, we shared some of the main outcomes and facts discovered in the previous research stages to ensure all the team had at least some ground-level knowledge.

In the following weeks, we started with an in-person session (which was great for getting to know each other a little more and gaining confidence as a team) but then moved to virtual meetings. These lasted between 2-3 hours each and were held once every 3-4 days, to try and keep a certain work rhythm.

Out of all the exercises originally proposed by the Lean Inception framework (approximately 10), we chose the ones we thought would be more fruitful, considering our team and project. The six exercises chosen were: Product Vision, Product Is / Is not / Does / Does not, Personas, Journey Mapping, Feature Brainstorming, and Feature Prioritization.

Throughout the sessions, we maintained a "Parking Lot" board to temporarily record ideas or discussions that arose but were not appropriate to address at the time. This method effectively kept the team focused and prevented any big distractions. Additionally, at the conclusion of the Lean Inception, we had a list of potential topics for future conversations.

For each exercise, we repeated the same structure: we first divided into two smaller groups to work separately, and finally came together to share our work and end up with one unified result. This structure let us have several significant discussions each time, challenging our ideas constantly.

So what were the main outcomes of our Lean Inception?

In terms of the product, we ended up with a consistent definition of what our MVP would be. Along with this, we clearly defined our target users and the key features the product should have to successfully address their needs.

As important as this sounds, I wouldn’t say that this was our most crucial outcome. For me, the Lean Inception proved to be an excellent team-building exercise. At the end of it, the team was fully aligned, motivated, and eager to continue its efforts to make this product a reality.

So what were the next steps? Well, in a nutshell, we decided it was important for the Machine Learning team to go back and further investigate the technical viability of such a product. It was paramount that before we engaged with any more potential users, we had at least some certainty that what we were proposing was feasible. You can learn about this particular process in this blog post by the Machine Learning team.

In the meantime, it was decided that the Design team would delve deeper into the competitors more thoroughly. We had no idea what we were about to uncover…

Horror stories and a new competitor

Now, let me tell you a scary story:

Once upon a time, a designer was scrolling through Instagram after a long day at work, admiring all the cute animals that passed before his eyes. As he scrolled through his feed, he came across an advertised post from a company he had never seen before. And this post depicted a product almost identical to the one he was working on.

The designer was shocked and scared. He immediately reached out to his team to share his findings. They all agreed that they needed to figure out what was happening and how to stay ahead of the game. They began researching the competitor and analyzing their product and their strategies.

As they dug deeper, they found that the competitor had been working on the product for much longer than they had and had already secured partnerships with important organizations. They were stunned and left feeling like their innovative idea had been taken from them.

Want to be more scared? This is a story based on real-life events. Blame it on my Instagram’s algorithm, that after detecting that I’ve been looking for sign language-related content, decided I needed to see this ad.

However, was there really anyone to blame? Of course, at first, we racked our brains thinking about how we could have missed it or if there was any way we could have found it earlier.

We are confident we took our steps correctly: we searched for competitors, analyzed their products, and kept an eye open for any new updates. Still, the truth is, these things happen more often than not. It’s a big world, so there’s always the possibility that a never-before-seen competitor is out there, hidden in plain sight (or Instagram ads).

Our next big challenge was determining what we wanted to do with this new information.

It felt like the moment in a horror movie when the group decides to split up, each venturing off into the dark and unknown. We knew it was time to part ways with this project, but the thought of having done all that for 'nothing’ made our hearts race with fear.

We took comfort in knowing that ultimately, our users’ needs were somehow going to be addressed by this newly found competitor. We didn’t see much sense in competing with an already established company, as our goal was to make this an open-source, non-profitable initiative.

While it was a bit disappointing, in the overall picture, we could all agree that the timing was great.

Final thoughts

Even though the project was scrapped, we were left with some important learnings:

Overall, the benefits of UX Research have been clearly highlighted: thanks to it, we were able to have a thorough understanding of the problem and the people affected and make knowledgeable decisions right from the start. It finally led us to find this competitor, so without that, we would have jumped right into developing the product and possibly met failure.

We tend to think engaging in UX Research is an expensive, resource-consuming process, but that’s not always true. We can still take full advantage of its benefits by picking the right tools and techniques for our project. Take for example our very own Lean Inception: while it's always preferable to prioritize running the full, original version of this framework, we found that you can still achieve great results by running a shorter, adapted version of it - if you can’t do the whole thing, it's still better to do at least some parts of it, rather than nothing at all.

In addition, we proved once again the advantages of working with diverse, multidisciplinary teams. It was an excellent opportunity to share knowledge and experiences with the team, while introducing some of our design practices to other areas of the company that may not have been familiar with them previously.

Finally, we can confirm that Design is a powerful tool for change: it's not just about creating a beautiful product, but about deeply understanding our users' needs and creating experiences that truly resonate with them.

At the end of the day, Design is about putting users first in everything we do. It's about making them feel heard, understood, and valued. By prioritizing user-centered design in any business strategy, we're not just creating better products - we're making a real difference in people's lives.