The first official mobile app
for SGI- USA

A UX Study Case by Martino Liu 

Product Designer at iTexico

As the biggest and more diverse Buddhist organization in the country, SGI-USA wanted to provide a mobile experience for the first time to its close to thirty-five thousand practitioners around the country. 

Problem Statement

The problem they wanted to solve was how to translate SGI daily and monthly practices into a mobile app. The challenge was to make an app that was helpful and easy to use so all members could engage with it as fast and simple as possible. It also needed to be available for both iOS and Android users.

Users & Audience

The SGI practitioners are very diverse in age and race, but somewhat similar in lifestyle because a common practice bounds them. They are around the 50k mark in the US.

Roles & Responsabilities

Sole UX Designer of this project, I collaborated closely with client stakeholders, our project manager, and 2 mobile developers. It was a project done remotely.

Scope & Constraints

There were no preconceptions about what to do and how to do it. All they needed was an easy to adopt mobile application since this was going to be the first official app for the SGI community in America. There were some constraints like the diversity of devices the practitioners had and the budget and time of the project. We opted to do a native Android first and then and iOS native app later for both smartphones and tablets.

 

Although there was not an explicit budget for user research, that was one of the first things I corrected since they wanted to jump to the whiteboard before getting a clear understanding of who they user persona was exactly.

 

We also needed to do some competitive analysis first to see and look at what was already out there and working for the community.

The Process

User

Research

User

Stories

Information Architecture

Wireframes

User

Flows

Prototyping

User

Testing

User Research

The first thing I did was to do some stakeholders interviews to get to know the practice of Nichiren Buddhism, I also needed to understand what SGI is, what their practitioners do and get familiar with the practice in general. There was no specific budget for User Research but still I had to take a weekend off to do a brief field study and explore the practice by going to the local SGI center in Guadalajara (I didn’t know there was one) and meet some people, do some contextual inquiries, some interviews, and immersive observation. I even got a book, the Lotus Sutra, from a coworker that I knew was practicing Buddhism and he actually was an SGI practitioner years before so I got to get more insights face-to-face, all this help me get acquainted with the practice and help resolve the design challenge in a better fashion.

User Stories

I got a concise list of requirements from the stakeholder's interviews. The main feature was to keep track of the Daimoku, which is a unit of measurement in their chants or prayers, and to have access to a whole range of other secondary features. 

Information Architecture

After taking a look and doing some competitive analysis with other apps in the market, I came with a better understanding of how the application should be organized and what feature it should have, so I started putting together an information architecture map and discussed it with the stakeholders until we came about a final distribution of the information.

Wireframes

The next needed step was to start putting some wireframes together to stat visualizing how the actual screen to screen interaction was going to work. Specially to start understanding how the layout of the app was going to be on each screen size and platform.

User Flows

Pencil and paper in hand I started generating some ideas on how to better solve the problem. Soon after a few iterations on the wireframes presented in Balsamiq, we realized that the sound of the Bell was key to the design of the main feature, the Daimoku tracker. So this concept of listening to a bell while chanting was incorporated at the early stages of the sketching phase thanks to some of the answers provided during the stakeholder's interviews that were not presented as a feature in the beginning. During this phase of the design process, the stakeholders iterated in as many as 3 times a week in order to sign off all the low fidelity wireframes until the completion of all features been sketched out and wireframed.

Prototype

Almost at the same time that I was presenting the wireframes, I needed to present the actual user flows for the stakeholders to understand how the users will be performing tasks within the app. In this iterations, we were defining the features while gaining a deeper understanding of the actual user flows. I created 4 prototypes, 2 for tablets versions and 2 for smartphones for each platform (iOS and Android). This helped the team and the stakeholders to come around the actual visual interface, it helped them see the actual final look and feel and we kept iterating over these prototypes to polish the design. The prototypes presented in InVision were a great tool to showcase every feature of the app, this helped us also to make better decisions by reducing the features in the app or mixing them in different ways, but we also needed to validate those decisions with users.

User Testing

Round # 1

As we were discussing the many features of the apps, I suggested the next effort to validate design decisions with user testing. We didn’t have a budget for this but we manage to get 3 internal users to go through the app and observe their behaviors, listen to their questions and thinking out loud sometimes. What we found after this internal user testing is that we needed to make the primary feature of the app, the Daimoku counter, more precise. 

 

The 3 users provided negative feedback regarding how confusing it was to sing or pray along the Daimoku counter. While they were singing or praying at their usual pace, they were getting a faster or slower count, therefore the friction. We had to include a setting to the counter in order to calibrate the count with the user's own speed. This helped bridge the gap between beginners and experienced practitioners and it helped get the foundation of a first-time app. 

 

Round # 2

We still needed to learn whether to have the counter visible all the time was, in fact, useful since all practitioners do all the time is get their eyes closed while praying. So we did another round of user testing with different people, this time the feedback on the counter was neutral, but we realized that the setting of the counter was difficult to access. 2 of the 3 users showed friction while trying to set the counter. 

 

This time instead of hiding the setting in the settings section, we had to come up with an idea to set up the counter directly from the counter screen, we decided to make the setting come up after tapping the counter making it also easy to decide whether to use the timer or the stopwatch mode of the counter, therefore removing that option from the settings section making it more intuitive and adding discoverability to the feature.

Final Design

After four months of design work, the app design was completed in 2 platforms; iOS and Android for both smartphone and tablet use. At the final cut, the app had 6 out of 10 original features making it easier to adopt an enabling the users to engage with it in a more focused manner, an important aspect for easier user adoption. One of the fine aspects of this final design was about the way the app was showing the successful achievement of goals within the app, they wanted fireworks. Yes, the request was very explicit and direct: “we want fireworks in the app”. I knew this was going to be a challenge since is more in the realm of game design, still I had to manage alongside one of the mobile developers to come up with a final proposal, in short, they liked it and we stick with it knowing that this, being outside of our skillset, could have been an opportunity to say no, or simply get an expert on this specific requirement and see how the stakeholders could have reacted, but pretty much we did get through.

 

Deliverables. A Design bundle including all original design files, notes, and digital documents. All product specifications were delivered to mobile developers using Zeplin. The prototype was delivered using the Invision app.

Outcomes & Lessons

We completed the challenge in time and in good form. It was an incredible experience to go through the whole process and give the development team a clear look into what a product design process should look like, definitely moving the team forward to become a user-centered product team.

logo-iteso.png
Martino Liu - Membership Certificate.jpg
seal-csm.png
  • LinkedIn - Black Circle
  • dribbble-icon
  • Behande