The 5th annual Localization Lab Summit was one of the largest and most professionally diverse, bringing volunteer contributors from around the globe along with developers, UX/UI designers and content creators working on Localization Lab supported projects and beyond.
With UX/UI designers from Okthanks, Simply Secure, Tor Project and Ura Design in attendance, we dedicated an entire session to the space where design, development and localization overlap and how co-design and better coordination can lead to more usable and culturally relevant tools.
With input from Eileen of Simply Secure, we decided on a “World Cafe” structure for the session which broke summit participants into small groups which would rotate every 15 minutes between 5 stations. Each station was facilitated by one of the designers and focused on a different question or topic related to design and localization.
Station 1: Elio (Ura Design, OONI Probe)
In our design session we discussed how we could address localization and design processes in an environment utilizing a building block approach. UX Design, User Research and Localization are 3 very interdependent elements and each of them can influence the other heavily in a development process. Having this in mind, our group came to the concept of functional sprints rather than handing off a feature to another team once it's "ready".
The potential advantages of this would be that team members from various disciplines would work closely together on the same feature, enabling short feedback cycles with the assumption that revisions can be handled faster than handing off deliverables from one team to the other. Releases would happen often with very small incremental changes.
The motivation behind this process is being able to spot issues right away as all team members still have control over the process. One downside to this could be the intense, yet slow development process, since all development is cut into small chunks. Of course this is all hypothetical based on our experience from other open source projects.
Last but not least, a big issue we identified is that current funding models are completely incompatible with more efficient ways of developing software, since a large number of grants are given out based on deliverables and a timeline which doesn't correspond with the actual development process.
Station 2: Tiffany (Okthanks)
At our station, the topic of discussion was feedback. We began by asking the question, "what motivates people to give feedback?" This led to some great conversations around gamification, recognition and thanking all those who contribute (in any capacity). We want to encourage feedback and help foster relationships, which may make individuals want to contribute in the future. It was clear people like to give feedback when something works really well or really poor. Which begs the question, how to make giving feedback easy? This led to conversations around the challenges of giving feedback. The process of giving feedback should be quick and easy and with a clear direction of what type of feedback is helpful or useful at that time. The goal of feedback should be to continue the cycle of engagement with end users and communities, therefore finding ways to get them invested in the process from the beginning, creating a long-term relationship and establishing that their feedback is valuable for the design of the solution, may help the overall goal of creating solutions better fit for communities. We also briefly made adjustments to a user story (I will include the photo here, in case you want to use it). Main takeaways, were:
say "Thank you!" to everyone!
If you can't get to the feedback or it's not in the current scope, communicate this when able.
Speak to the impact, show impact, or communicate it someway....The feedback you give is valuable in making decisions for the design and development process. Shaping future products and goodness.
Maybe giving feedback should be anonymous by default, uncheck a box if you want to be known.
Station 3: Eileen (Simply Secure)
This session looked at the other side of user research: how to incorporate user feedback into Internet freedom projects. We began by mapping types of feedback the projects receive, either reactively or proactively. Reactive feedback can be incoming messages, bug reports, social media comments or in-person complaints. Proactive feedback, on the other hand, describes information gathering as part of a user research process, such as survey data, tracking data, or user interviews, testing, and observations.
In a next step, the group looked at emerging issues with the current forms of feedback gathering. Beyond the usual complaints (feedback is often too little information, and too negative), three systematic issues stand out: with reactive feedback, it is difficult to understand underlying issues (asking ‘why’). It also is heavily biased toward superficial or minor changes, and leaves out important requests. Finally, users are good at expressing what they want, but not skilled in identifying what they need. This makes adapting the project to user feedback especially hard.
Lastly, the group looked at existing ways to incorporate incoming feedback, such as issue trackers, systems for prioritisation, team communication tools, and visualisations. People agreed that factors for triaging include: number of people requesting feature, funding attached to issue, difficulty of implementation, as well as how important the team deemed the request ("security and privacy matter more than colours and buttons”). For contributors, people brainstormed ways to include them. At the very least, they deserve a response; in the best case, they can be invited for testing, and attributed in some way. Gifts and other types of compensations are options, too.
Station 4: Antonela (Tor Project)
Station 5: Kaci (Okthanks)
I held the station of “Designer FAQ/AMA”. The first round of participants took a little bit to get started because it was such a broad topic to discuss. Especially for those who hadn’t worked closely with designers before. Once conversation got going, though I could tell that everyone was interested. Once the rounds kept going, I could tell the participants who have worked closely with designers and have had burning questions for ages ;) these almost always had an “oh yeah!” or " Good question” mumbled in the background.
As a designer who deals more intently with graphics and interface, and who has a bit of a different working environment (since we work so closely with our developers), I sometimes get thrown by questions or assumptions that others have about the design process so I was a bit nervous. But I think the session went very well! The two biggest takeaways that we had were (note: these answers are my opinion, and could very much be discussed among other designers):
Have designers in on the project as early as possible! And if you are having to choose between UX and UI designers in your budget, choose UX — it’s better to have something ugly that works than something pretty that doesn’t work. :)
This could help with the frustrations of them designing solutions that have already been tried or them not understanding the users. Designers are your friends! We want to help and we want to understand the project and make beautiful, seamless, helpful solutions. The more we know and the more we learn throughout the project the more productive the entire team’s time can be because less time is spent explaining all of the “known” info to the designers.
Push for Marketing Budgets.
Many frustrations of the participants dealt directly with adoption/putting things in front of users, and how to make tools look good. Overall, designers have to design within the means of the project scope. The more the project is set up for design and for visuals, the more time the designer can spend, the better it looks! As designers, we want our work to also help people and to work and to be used!