Revamping the Experience for the
Government Affairs Professionals

A UX Study Case by Martino Liu, Scrum Master at iTexico

BIPAC is one of the most important players in the political spectrum when talking about political enterprise platforms to leverage the power of people and coming close to legislators that are in favor or against business interests.

Problem Statement

BIPAC had a technological venture partner that for many reasons not covered in this study case they stopped developing the right way and was forcing BIPAC's staff work in a very complicated manner and most of the time having to deal with member reports of things not working properly on the platform.


By getting rid of that unfunctional partnership they were left with a Frankenstein platform that they needed to stabilize first and then shut down the legacy system to move to a more stable, functional and modern platform that could serve better their members base.


Our challenge was to plan work around understanding the legacy platform while making the propper improvements in the Frankenstein platform developed by the ex-partner by taking care of sudden bugs and client reports of features not working, sites falling down and security concerns all while managing a reduced team and budget with a specific shutdown date and the desire to build a more stable platform version that could be actually promoted among members without confidence and security issues to help the business grow and consolidate as a prime player in the industry.

Users & Audience

BIPAC member base represents more than 400 big corporations in America, who at the same time impact millions of employees across America. 


The users we kept in mind throughout the process were the so-called Government Affairs Professionals who do the tasks directly into the platform and create websites to communicate messages to their grassroots employees and the registered PAC contributors, also the other types of users we kept in records.

Roles & Responsabilities

I was assigned to this project as the principal designer and the Scrum Master. My responsibilities as a designer were to collect all product owner

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





Information Architecture







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.


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.


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.

Martino Liu - Membership Certificate.jpg
  • LinkedIn - Black Circle
  • dribbble-icon
  • Behande