I recently entered a project in mid-stream: most of the visual design and interactions had been done, and coding was well underway. There were only a few weeks left, and my main responsibilities were to further refine the existing interactions and identify any use cases not previously surfaced. When I started on the project, the most pressing concern on our internal team was a particular business requirement specified by our clients: a Japanese keyboard. The team had been nervous about this because we were working off an open-source framework that didn’t natively support Japanese language functionality.
There were two possible solutions: we either had to create a Japanese keyboard from scratch (and the supporting features of translating syllabic, or kana, script to logographic characters, kanji), or take advantage of the the current language API available and modify it. Unfortunately, once we looked at the API, we quickly realized it was not scalable since Japanese is not contained to 26 Roman characters and the API was configured with that particular assumption. There were other considerations as well, such as the fact that we would need to account for multiple methods of typing, the ability to toggle between the keyboards, and the limited time we had to produce the keyboard. Both options were looking very iffy.
Finally, I took a step back. I stopped trying to design around the issue, and began wondering why we needed this keyboard and just how critical it was for users to have access to it. Users would already have access to the English language keyboard, so I didn’t think it necessarily had to be a high-priority feature. As it turned out, the keyboard would only live on one particular section of the site, where users would enter their wifi password. When I found out this was the case, I thought back to the time I’ve spent in Taiwan and China, both countries that use non-Roman script. I couldn’t remember whether my passwords were written in Chinese or English, so I asked a bilingual friend what he did when he was back in Japan. The answer surprised me, and also solved our problem: wifi passwords are written in Roman characters. I confirmed with a few other colleagues who spend significant amounts of time in other countries and they all agreed. We didn’t need a Japanese keyboard.
The time that our team spent stressing over this issue could have been solved if we had been more thoughtful about the intent of the requirements. Although I’m usually involved with the requirements gathering and writing process, I wasn’t for this particular project, and I didn’t vet the document for any inconsistencies or instances of backseat designing. The issue with the latter is that people often express larger ideas and solutions through designs, so while it’s fine to use design to explain a concept, it rarely tackles the foundational problem. Here, the main issue was that our software system needed to be able to accept wifi passwords for users in Japan as well as in the States. The design solution written into the Business Requirements Document and offered to the design team was to create both Japanese and English language keyboards, which actually didn’t address the aforementioned user need. What did solve the need, however, was identifying the user story: Japanese-language and English-language users must be able to enter wifi passwords. The most valuable lesson I gleaned from this experience was that I always need to perform my due diligence in understanding the purpose of each proposed feature, user story, or requirement and to make sure design helps users accomplish a goal.