Product Design (Case Study): Designing and Launching FiscalNote Mobile v 1.0

About FiscalNote

FiscalNote is on a mission to build the world’s most powerful platform for analyzing government risk. Every day, FiscalNote transforms the way global organizations work by unlocking legislative and regulatory data to make it accessible and actionable. For organizations facing government impact, FiscalNote is the platform for professionals to plan and execute their organization’s government risk strategy. Organizations rely on FiscalNote because of its accurate and real-time information, cutting-edge analytics, and ease of use.

The Problem

In early August 2015, many of FiscalNote’s users were users of one of FiscalNote’s flagship product, Prophecy. Prophecy’s core users are state lobbyists who travel very often. During state legislative sessions from January to July, some are in as many as four state capitols in one week, during which they often only use their laptop before 8am and after 10pm. In order to better serve our users when the sessions started the following year in January 2016 and differentiate ourselves from competitors, we wanted to launch an minimum viable product (MVP) of a native mobile app. FiscalNote Mobile would be first launched on iOS since our research demonstrated that was the mobile OS that the majority of our users accessed our application from via mobile web. The mobile app would have limited features compared to our web app for the first release, but the features in the first release would be the features most relevant to a traveling policy professional, and the app’s capabilities would grow over time.



My Role

Lead Product Designer (UX and UI Design) and UX Researcher:
I was the lead product designer and UX researcher on this product launch (though I often worked on several product design projects concurrently, this was my top priority), and was responsible for the visual UI, UX, and interaction design of the product, as well as leading up the user research to ensure that the designs of the features in the MVP met user goals. I produced journey maps, low-fidelity wireframes, and high-fidelity interactive mockups and prototypes, but most importantly, UX research was a continuous feedback loop to inform better designs. I also conducted user interviews and guerrilla usability tests in the field, planned and executed the internal beta testing program with employees, the internal usability testing sessions with employees, and the external beta testing program with customers, and led ongoing design sessions to synthesize findings from user feedback and create actionable product recommendations and design visions. In the design role, I worked most closely with two mobile engineers for design reviews and iterating on different design options, and one product designer on the web team, one frontend engineer on the web team, and one product manager for design reviews and alignment on interaction design patterns, iconography, and copywriting changes we were making on the web app concurrently.

Product Manager:
I joined the project about a month after planning had begun, and while I did not specify the initial MVP feature requirements, I adapted them and served as the product manager for everything thereafter: I wrote and finalized the product brief as we made changes over time, prioritized and made difficult tradeoff decisions between usability and feasibility, and managed the go-to-market handoff to product marketing. In the product management role, I worked most closely with two members of the marketing team for producing go to market (GTM) deliverables, and two product managers and one frontend engineer for alignment between the web and mobile product leads on changes we were making to the product on the web app concurrently.


“Mobile is so far ahead in terms of user experience…it shows, great work.”
-Vlad Eidelman, VP of Research/Data Science at FiscalNote

I’ve only poked around a little bit on the mobile app, but it’s absolutely lovely to look at and (so far) very easy to use. Amazing work by your team!”
-Amy, Director of State Government Affairs at an Education Nonprofit (a current FiscalNote customer)


Business and Design Goals

  1. Driving a “Mobile-First” Product Strategy:
    In the designing and building the mobile application, we made several notable achievements that were not yet accomplished on the web application. For example, three features that were implemented on the mobile platform first were, 1. an in-app onboarding demonstrating how to use the key features (we expect that an in-app onboarding would drive increased usage not only for current customers but also for prospective customers, leading to a lift in our opportunity-to-close conversion rate to help us hit our end-of-year sales target), 2. calendar integration so a user could add an upcoming scheduled committee hearing to their calendar, and 3. sorting legislators by if they voted yes/no so a user could quickly see who was for or against them on a bill (and in future releases, be able to contact everyone who voted yes or everyone who voted no). Additionally, on the usability side, the product was designed such that a call to action (watch this bill) would be disabled until the user selected at least one bill first, something that was not yet present on the web app yet at the time due to design debt incurred in the early stages of the web app MVP product development.
  2. Increasing Revenue and Reducing Churn:
    In the last quarter of the year, one of the leading priorities for the entire company, including the product department, was to focus on initiatives that would support increasing annual recurring revenue (ARR) and/or reducing churn. Developing the mobile product MVP would support the Business Development team in closing new business with prospects and the Customer Success team in retaining existing business with current customers.
  3. Increasing User Engagement and Driving Adoption:
    The most engaged users on our application are the users who regularly track bills – tracking a bill means they want to continue to receive email alerts on updates to the bill, and when they do, this will drive them to go back to the application because they’ll want to see details on what the update is. With the features in the mobile MVP, I decided there were two core interactions we wanted to support users to help them meet their goals: 1. being able to keep up with their work on the go with the ability to scroll through newly introduced bills, decide which ones were relevant to track, and then track it, and 2. being able to prep for testifying at a committee hearing with the ability to quickly look up a bill page and see the latest updates

The mobile team rocks; and your designs rock! It is an incredibly good app.
– Ajay Chadha, VP of Engineering at FiscalNote

I honestly think that the mobile app is going to end up being the key tool for my team…you guys are great!”
-Brendon, Government Relations Project Manager at a Healthcare Company (a current FiscalNote customer in the beta testing program)


Challenges

  1. During this time, we were making a number of design changes to navigation UI of the web platform and its elements: standardizing interaction design patterns across features, standardizing custom iconography and their color variants, changing the naming for two of the core features critical to the user’s workflow. Making sure the user’s experience across mobile and web would be consistent and intuitive required close collaboration with the web team and staying updated on the design direction for the product experience across both the mobile and web platforms. To support this goal, a senior product designer and I put together a style guide to guide our product design visual system.
  2. Additionally, we were releasing several new features on the web application, many of which would be relevant to the future product roadmap for mobile, including shareable links and saved search. Pushing for critically thinking about the mobile implementation of different design options for the new features was and will continue to be a major challenge.

The new mobile app is slick!”
– Ross, Director of Policy, Advocacy, and Research at an Education Nonprofit (a current FiscalNote customer in the beta testing program).

After tweeting “FiscalNote Mobile will be a game changer for state gov pros”, Ross then also wrote an email to his VP, “Thanks for signing us up with FiscalNote. They are great group to work with. The mobile app will be a particularly useful resource when traveling.”


Process

My design process for the Mobile MVP involved: conducting user research and building understanding, synthesizing findings and mapping user journeys, mapping user needs to screen flows through information architecture and interaction design, polishing the visual design to maintain brand consistency, prototyping and usability testing, iterating and changing the design based on feedback, and prototyping and usability testing again. For this particular product launch, because we wanted to get the information architecture right and we were on a tight deadline, we chose to do the final UI and visual design polishing last.

  1. Conducting User Research:
    My colleague (a product manager) and I spent dozens of hours interviewing users in their offices around DC and in coffee shops near Capitol Hill to gather insights to inform our next quarter’s product roadmap. Our findings about their mobile usage gave us a better understanding of their needs and how we could launch a mobile product to meet their goals better while they were traveling for work.
  2. Synthesizing Findings and Mapping User Journeys:
    To synthesize the insights we gathered through user research, I took quotes from our user interviews and grouped them by theme. Under each theme, I posed a “How might we…?” question and invited the entire company to participate in the ideation process with me. Here are a few quotes from our interview-based user research sprint:

    “When I’m on the road, I won’t get to my computer until 10 pm, or 7 am. I’m highly reliant on phone, but sometimes cell phone coverage is a challenge. And if an app doesn’t generate quickly, I’ll default to email. “ -Andy, Partner at a Lobbying Firm
    “Trying to keep up with everything, between flights, especially if a flight doesn’t have Wi-Fi is a pain. If I’m flying across the country – I’m not going to have a whole lot of time to make sure I’ve looked at all the bills for the day – we have the ability to log in and look at all our documents on the internal shared drive – but it’s a pain when I’m on the plane for some reason – I’m looking for my saved letters for an issue – I never write anything fresh unless I absolutely have to.” -Sean, Director of State Government Affairs at a Healthcare Trade Association
    “I rely on travel apps on my phone, because if there’s a delay, it ruins my day” -Anne, Director of State Government Affairs at a Pharmaceuticals Company
    “There’s a list of bills I check for a bill hearing – especially since I have to book travel to get to those places.” -Owen, Director of State Government Affairs at a Consumer Products Trade Association

    Then, I asked, “How might we…empower users to keep up with their work while traveling?”
    To guide the ideation, I developed four design personas who would likely to use the mobile product and led a lunchtime training session on personas, which was attended by 20-30 employees.
    state director stacy
    State Director Stacy is an example of one of the personas and is the primary persona for the features in our MVP requirements. Stacy, a State Government Affairs Director at a Private Company, spends her days meeting with state legislators. She logs into the web application daily and receives a daily digest email for newly introduced bills in the 10 states she covers, and email alerts every four hours for updates to bills she’s deemed relevant and wants to follow as they move through the legislative process. Her main goals are: quickly looking up a bill if it’s mentioned in a meeting with coalition members, managing updates for newly introduced legislation and changes to legislation she’s monitoring, and having an easy way to decide which bills to monitor.
  3. Mapping User Needs to Screen Flows:
    I created site flow diagrams to map the basic functionality of the features of the Mobile MVP. The interaction design focused on the data users would need to see, what they would need to do with it, and how they navigated the app.
    mobile navigation flows

    In this phase of the design process, we uncovered that one key design decision and feature change we would want to make is giving users the ability to view an in-app onboarding. In the early stage, one design concept of the onboarding was a series of tutorial screens like this:
    mobile in-app onboarding - stage 1, option 1
    However, after after discussing as a team, we decided to adapt our approach. We wanted a more interactive experience in the initial onboarding, as a well as intuitive UI paired with microinteractions and microcopy to guide ongoing onboarding (for example, help copy in confirm delete actions to continuous train users on how to use the app). And after finding a library on Github for an interactive onboarding, we knew doing so in a short timeframe would be feasible. The onboarding design concept adapted to look more like this:
    mobile in-app onboarding - stage 2
    Between these screens, there would be animations of the actions of searching, clicking on a bill card, watching a bill, and more. The actions were performed on bills that were hardcoded in order to minimize the chance of edge cases (for example, the user misspelling a search term and seeing no search results).
  4. Adding the Visual Design:
    Of the several possible interaction flows I sketched, I chose to mock up a few as high-fidelity prototypes. After we finalized the interaction flows, we polished the visual design. We iterated on the visual design several times. In particular, here’s how the iconography and the colors evolved over time:

    File Type Icons
    I noticed that in the bill text section on the bill page of the web app, it was difficult for users to be able to understand how bill text files differed.
    bill texts on webTo make it easier for users to visually see the difference between different file types of bill texts, I created custom file type icons, pixel by pixel, from scratch.
    custom file type icons
    The goal was to make the bill texts easier to identify, especially when combined with a vertical layout of the bill texts with full titles.
    bill texts on mobileDue to limitations at the time in our data validation process, we were unable to display dates for each bill text but in our longer term product roadmap, we would want to display bill texts and amendments separately, in chronological order, with a custom icon for each document type.Navigation Toolbar Icons
    In the navigation toolbar, we changed from a set of standard icons from one icon font to a set of custom icons my colleague, a senior product designer, created, pixel by pixel, from scratch. However, after testing the custom icons on both light and dark backgrounds on both mobile and web and discussing with our lead frontend engineer, we decided to create a custom set of standard icons from multiple icon fonts, which the product design team would curate and maintain. And to touch up the product and make the branding consistent with the company brand, we changed the colors of different areas of the app over time.
    ios nav bar change
  5. Iterating and Incorporating Feedback:
    A month before launch, we opened the app to beta testers, internally to coworkers and externally to customers. At the time of beta testing, the design looked like this:
    ios before beta testing During internal usability testing and external customer beta testing, we noticed few users were able to find the ability to watch a bill from search, the discovery alert feed, and the watchlists. Because of this new information, we had to backtrack and redesign the call to action for watching bills. We decided to make a copy change from “Edit” to “Select”, and also integrate teaching users to swipe to watch a single bill into the in-app onboarding. We specifically chose not to change the copy to “Watch” because future iterations of the product would include other calls to action. After we made the changes, the design looked more like this:

    Additionally, to optimize the mobile experience, we redesigned the bill card UI, and the information hierarchy (for example, the size and weight of the typography) was informed by UX research. Here are two initial design concepts out of many that we chose to refine. We presented the state and the bill number together. In the web app, the bill number is listed before the state, but we noticed that users tended to refer to bills colloquially as “PA SB 198”, so our design reflected what would be most intuitive to the user.
    mobile bill card UI - stage 2
    However, we were never completely happy with the design. Auto-layout didn’t render the design very well in either edit/selection mode or for Basic users (the design on the left with analytics scores is for Plus users, the design on the right without the scores is for Basic users). Additionally, at the same time, the web team was working on a redesign of the bill cards as well, which would include branding the forecast scores together as one unit. They were planning on shipping the branded forecast scores in a few weeks, around when the mobile app would be released in the App Store. The final kicker was that a week before launch, we realized based on feedback from internal testers that the color of the bill number was not ideal from an accessibility point of view for colorblind people. I worked through a few different design concepts with a mobile engineer, and refined with after some feedback from a senior product designer and our lead frontend engineer from the web team and together, we polished up and redesigned the bill cards to look like this:


    As a final visual touch and to improve the new user experience, we redesigned the empty states, from this:

    to this:
    mobile empty states - final

  6. Final Design:
    After we made the changes, it was time to submit to the App Store and get ready for launch. These are the screenshots of the design we submitted to the App Store:



    Video produced by our product marketing manager.

    To prepare for the launch, I worked closely with a product marketing manager and other members of our marketing team to get several GTM assets ready for launch day: a product marketing page (FiscalNote Mobile), a product marketing video, and more. If you’d like to try out the app yourself, you can download it on the App Store, where it has several positive reviews from users.
    FN App Reviews


“Wow. This update is so sleek! Big shoutout to the mobile team.”
– Tim Hwang, CEO at FiscalNote

Good lord, this build is awesome.
– Nate Sullivan, Product Marketing Manager at FiscalNote


Outcomes and Learnings

Constraints Breed Creativity:
I started on this on August 1 and the app was scheduled to launch December 1 – during this time, I was also staffed on 3-4 projects at the same time. For the first two months, the mobile team was two: one mobile engineer and myself. During the last two months, another mobile engineer joined the team, bringing the total to three. We worked together on design reviews and design often happened less than one week before development began, though they often occurred concurrently as well since we sometimes wanted to adjust a design while in development. This meant a concept could go from an idea sketched in a notebook to a finalized feature in the latest weekly build on TestFlight in 1-2 weeks. A week before we were scheduled to submit to the App Store, we decided to redesign the bill card UI. The final bill card UI when from ideation to final design within two days, and into production/the next build and the hands of beta testers within one week.

Adaptability Facilitates Better Collaboration:
In the middle of this project, our mobile engineer asked me to send him assets in Sketch instead of Illustrator. I had already created almost all our screens in Illustrator, and the thought of a blank slate and stumbling to learn a new software tool made me initially hesitant. But I did some research and found out why people use Sketch to better facilitate close collaboration between design and frontend development, and decided to take the plunge. It turned out the blank slate helped me become more comfortable with not being overly attached to earlier design concepts. The hardest part about design is throwing out a design you spent hours on that was 100% envisioned by you, and deciding to implement a design that you spent less time on that is 50% your initial vision, 10% your team’s feedback, 25% feedback from users, and 15% your team’s feedback again. But if the result is a better design for the user’s goal, then you’ve achieved the goal of designing a great product, no matter how you feel.


Future Roadmap

Next quarter, we’ll be designing and shipping (subject to change) improved push notifications, legislator pages, shareable links, similar bills, and universal links.


Follow me on Twitter and Medium

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s