Designing web applications in Myanmar was quite an adventure. For most people in this beautiful country, their first internet experience was on a modern Android device with a 360 X 480 display running the latest version of Facebook. Because of this we realized that most Burmese internet users have never developed the conventions that we westerners are so accustomed to such as blue links on a neutral background.
In an effort to address this challenge, these are the questions that we started asking;
What are the Burmese user's current behaviors, motivations and needs and how might we design with these considerations front of mind?
Using these questions as a starting point, I did some initial research online. Here's what I came up with.
Doing a bit of Google search acrobatics resulted in some interesting findings about Myanmar including these stats on needs and motivations: 46% Build their own homes, 22.5% Own cats, and 74% of the country earns between 0 and $333 USD per month. This was useful for providing context and empathy but we needed more. Juan (Our amazing product owner) and I started looking at the analytics. We asked; what are the current behaviors?
Using tools like Google analytics, Hotjar and Crazy Egg we were able to get a very well defined picture of the user's existing behaviors. It was a lot of fun to use these quantitative insights alongside the qualitative insights we would gather later while on the ground doing field research in Yangon. Speaking of field research, soon after that Juan and I hopped a plane to Myanmar! Here's what happened next...
Exploring Yangon was a singular experience which felt a bit like going back in time. We had the team recruit some representative users ahead of time so we could do some task based analysis of the existing site/application in the same way we would normally use a prototype so we could see first hand how they used it. One of the first things we noticed was that the users were experts at scrolling. They scrolled a lot! From the top of the page all the way into the footer, there was a sense of urgency shown by most users which seemed to indicate a desire to see everything on the entire page before navigating or tapping on anything else. The second interesting behavior we observed was their reliance on Facebook for pretty much everything. For them it seemed Facebook was the internet! The third insight we found was that most if not all people hated typing. Entering text into a field was a massive obstacle for our users. We didn't understand why at the time but we came to find out later that their earliest webfont was downloaded by some unscrupulous people who in order to cover their tracks, moved around a bunch of the unicode characters making their font non-compliant with unicode standards and their internet content created with this font unreadable to the rest of the world! What a mess! At least at this point we knew enough to get started...
Given the complexity of the interaction design model we were dealing with, we spent a lot of time deep in conversations at the whiteboard before we moved in to low fidelity sketched wireframes. These disposable sketches helped move the conversation along quickly without investing into the traditionally bloated wireframes and documentation inherent in projects like these.
Once the interaction design model was finalized and the wireframe sketches signed off, we moved to Sketch and Invision to create high fidelity mockups and prototypes. This was very helpful for testing, getting signoff from stakeholders and communicating the interaction designs to the developers.
Once the final designs and Prototype were signed off on, we used Zeplin, a fantastic Sketch plugin, to export a good amount of front end code and excellent layout specs for our front end developers to consume. This accelerated our design process so much that we were often 2 sprints ahead of the developers. This gave us more time to do research and testing on the next features before design specs were required.
One of the final projects I worked on in our Bangkok office was shipping specs and process for a React Component Library. This allowed developers to copy snippets of code for commonly used components without building them from scratch and also helped maintain a much leaner code base and consistency across the platform's UI.
More to come soon!