Visual Superscript is a custom web app for retail pharmacy’s day-to-day operation of prescribing drugs. Currently in beta release with 10 pharmacy groups across the U.S. and South America. Pharmacy owners have signed up to subscribe to production version, promising client additional recurring revenue.
2018-2021 • Research • Product Design • Legacy System Redesign
DAA provides software for retail pharmacies to manage their day-to-day operations. Visual Superscript (VSS) is a key product born from a collaborative effort between pharmacists and software engineers over the last 20+ years and currently used in 600+ US pharmacies.
DAA asked us to help create a modernized solution which will enhance their offering and allow them to regain lost market share while positioning themselves in emerging growth areas by overhauling their legacy desktop system and moving it to the cloud. The new system should enable pharmacies to focus more on productivity and growing business with a fast web application that gives owners freedom to manage their pharmacies with ease from anywhere.
As sole designer, I was responsible for:
- End-to-end product design:
- Feature discovery
- Information architecture
- Visual design
- Iterative UI updates based on feedback and user observation
- Collaborated with a team of engineers, business analyst, PM and client stakeholders to ship product.
- Iterating existing designs based on user and stakeholder feedback.
- Maintaining UX consistency between U.S. and international versions.
- Creating and maintaining a design system in Sketch/Abstract, later Figma.
Case study story map
In a complex system, a task crosses multiple features. This case study explores one of the essential tasks of a pharmacist: filling a prescription. 
Scroll below to see in-depth story behind each asterisks (*)
Patient Rx History
The system did not differentiate between new prescriptions and refills, causing accurate tracking impossible. How might we improve patient history to provide better visibility to past, current, and future?First Iteration
Our priority was to differentiate refills from Rxs with minimal changes to the existing UI. We implemented tab UI to switch between two views sorting by most recent Rx Date and Fill date by default. Rx History is the default selected tab. This design fulfilled our stakeholder requirements.
However, during testing, we found that users still can’t quickly find the fill related to the Rx and vice versa. It turns out switching back and forth requires a lot of mental power from users because they need to remember Rx numbers that could be 6+ digits long.
Added Complexity
As we kept demo-ing to users, we discovered that users also want to:
- Quickly identify which rxs are expired
- Instantly see which Rx are due for refills
How could we illustrate parent-child relationship clearer to the user?
Using our understanding of the rx/fill model, we mirrored the structure as nested table because wanted to build in a visual way for pharmacist to track using a simplified timeline graph.
Final Design
Turns out the nested table hindered pharmacist productivity because they have to dig to find information. In the end, we kept the Rx and Fill table separate as default while adding a calendar view for pharmacists to track patient’s adherence month-by-month more easily.
Batch Filling
Filling prescriptions efficiently is an important part of a pharmacist’s job, especially at a high-volume location. The current system allowed the user to select multiple Rxs to view, however did not allow for batch actions. I iterated on the feature to address user wants below:
Billing Multiple Insurance Claims
After inputting Rx details, pharmacist transmit Rxs for billing before filling the drugs. Patient could pay out-of-pocket or with insurance. Sometimes a patient has more than one insurances that could pay for a single Rx. Scenario below illustrate billing to multiple insurances to help patients pay as little copay as possible.Rejected-paid-no copay scenario:
Original price = $7.28
Insurance #1 = $0 (rejected claim)
Insurance #2 = -$7.28 (paid in full)
Copay price = $0
Original price = $7.28
Insurance #1 = $0 (rejected claim)
Insurance #2 = -$7.28 (paid in full)
Copay price = $0
Paid-paid-copay scenario:
Original price = $807
Insurance #1 = -$102 (paid a portion of claim)
Insurance #2 = -$100
Copay price = $605
Original price = $807
Insurance #1 = -$102 (paid a portion of claim)
Insurance #2 = -$100
Copay price = $605
Impact
The system is currently in beta release with 10 pharmacy groups across the U.S. and South America. All participating pharmacy owners have signed up to subscribed to production version and are excited to start using it daily.Learnings
- Finding ways to convince clients to do user testing︎︎︎ proved to be a worthwhile personal investment as we were able to gather edge cases from users that allowed us to iterate the product better.
- You are not your user. I learned that treating my users as teachers, asking for clarifications and not taking their negative feedback personally helped made the product better.
- You are only as good as your team. This complex overhaul wouldn’t have been possible without skillful developers and PM. Crafting the UX/UI is the visible part but so many things that make this product good are due to the hard work of entire team.
Do you love that super-fast internet at home?
Most likely telecom technicians have installed fiber optic lines along your street and into your walls that transform into precious WiFi.
To install this essential infrastructure, they need to use specialized tools made by companies like Jonard Tools. Jonard makes tools for cable, fiber-optics, telecom, and solar technicians in the field.
2019 • Research • Product Design
My Role
Their brief was broad, so we started with a lean canvas exercise to further understand what our priorities should be in the agreed time & budget. We agreed that increasing customer engagement with the brand should be our main priority for the redesign.
![]()
Identifying user groups & their goals
Our client did not have direct access to end-users. To circumvent that, we conducted a written survey and followed up with a verbal interview with 10 Customer Support employees who take calls from customers. Jonard pride itself on being an industry expert, releasing innovative well-made tools for the field every month.
We found that finding correct product specs, technical application, and product availability were the most frequently requested information, while promotional material such as news and events were the least requested.
![]()
- Identified user goals & their relationship to the business
- Defined user behavior by analyzing user flow in Google Analytics and customer support staff interviews
- Gathered product requirements
- UX and visual design the entire site
- Collaborated with business analyst, PM, and developers to launch the website in 8 months
Challenge
“We know our site sucks, help us make it better.”
Their brief was broad, so we started with a lean canvas exercise to further understand what our priorities should be in the agreed time & budget. We agreed that increasing customer engagement with the brand should be our main priority for the redesign.
Using lean canvas exercise, the client and I identified general business goals and functions. Highlighted areas show issues that could be solved in our website redesign.
Identifying user groups & their goals
Our client did not have direct access to end-users. To circumvent that, we conducted a written survey and followed up with a verbal interview with 10 Customer Support employees who take calls from customers. Jonard pride itself on being an industry expert, releasing innovative well-made tools for the field every month.
We found that finding correct product specs, technical application, and product availability were the most frequently requested information, while promotional material such as news and events were the least requested.
We took data samples from the past year and found that navigating to an individual product or product categories was working well, but analytics showed that people were going back and forth to view several products.
Each product with the smallest difference (e.g. a ¼”, ½”, ¾” pliers have 3 different SKUs) is therefore treated as its page. There was a need for comparison and a better way to connect SKUs.
Each product with the smallest difference (e.g. a ¼”, ½”, ¾” pliers have 3 different SKUs) is therefore treated as its page. There was a need for comparison and a better way to connect SKUs.
Designing a better product relationship
After studying 300+ products in the catalog, I identified 5 distinct ways that product detail could be shown and developed templates for each.
Search Results & Product Comparison
Based on analytics insight that users use the site to compare specs, we introduced a comparison tool on the search results & product category level so users could quickly compare product specs. After launch analytics showed that 8 out of 20 top exit pages were product comparison pages.
Based on stakeholder feedback, comparing detailed specs such as physical size, weight, material, number of slots for kits were not valuable for users. They wanted to compare the contents of a kit to another.
The products are the core attraction, but other avenues of engagement are also important
Learning Center, Where to Buy, News and Homepage
After establishing our product relationship, search, and produc detail, we addressed other frequent reasons why users would visit the website, such as where to buy and learning how to use the tools. Although we would have loved to give users access to directly buy the tools online, the indirect distribution model didn’t allow us to immediately point to a particular shop to buy.
To teach users about product applications, we set up a learning center, combining tutorial videos from YouTube with links to our product detail pages.
Impact
After releasing in early 2020, we took a 6 months sample from February - August 2020 and compared them to the same timeframe the previous year. On average, new users increased by 112%, unique pageviews by 29.3%, and average time on page by 20.6%.
Learnings
- There’s no better position to design from than to be a subject matter expert. By taking my time to understand Jonard’s business, users and products, I was able to better design a suitable site. As a bonus, becoming an SME helped greatly in gaining client trust.
- It’s better to ideate together with engineers and business folks than to design in a silo. By putting our heads together we had much better ideas and saved so much time negotiating back and forth. Agile for the win!
- There will always be features and designs that could be improved; but within a limited scope, striking a good balance between design, user goals, technical feasibility, time, brand and business goals are just as important as creating a super creative, award-winning site.
Direct Merchant Financing Portal is a custom web app for a midwestern bank to help simplify purchasing and repayment for farmers by integrating financing into the sales process. At launch, this product help grew bank revenue by 3X.
2020 • Research • Product Design
First Mid is one of the largest agricultural lender banks in the Midwest region. They offer financing to farmers for operating needs such as buying fertilizer, seed, livestock, and more. To win 3X more business from a large merchant, our client wanted a custom web app to streamline financing customers and merchant transactions. If successful, the system will be rolled out for other large merchants.
As sole designer, I was responsible for:
- Identifying relevant user groups, goals and pain points.
- Balancing aesthetic and functionality with development effort to build a working, secure and stable system in 6 months.
- End-to-end product design from the ground up:
- Research & user journey
- Information architecture & wireframes
- Visual design
- Iterative UI updates based on feedback and user observation
- Design handoff to developer
Defining product goals and direction
Product goal:
Simplify purchasing and repayment for farmers by integrating financing into the sales process.
Farmers could apply for a loan through the bank and have credit released automatically to the merchan and pay loans
Bankers could enter new and edit updated application, approve/reject loans,track statu,service active loans, and easily download reports.
Merchants could view loan application status & account, initiate withdrawals and refund and download reports
Current pain points
Farmers are responsible for managing loan payments between bank(s) and merchant. A new service would offer a convenient option for a bank already partnered with the merchant they want to buy from.
On the bank side, everything is still manually done via paper applications, and calculations were done in Excel sheets.
The merchant has difficulty keeping track of
approved loans, payments, and refund report correspondence with banks and customers.
High-Level User Journey
After identifying 3 usergroups, I mapped out high level touchpoints.
Early Wireframes
Designs
Tackling from the usertype most accessible to me, I started designing for bank users. With a tight deadline and demand for robust sorting and filtering, our team decided to leveraged a third-party component (AG Grid) for our grid with minimal visual customization
Credit Team's Homepage (Accounts)
The account page serves as a single source of truth between credit and loan team.
Exposing application and loan statuses as part of the grid allows users to search for customer information with custom filters.
After distilling the loan application process, we decided on 3 main steps: Application Input, Decision Input and Finalize Decision. When the credit team has all the information, this is a linear, straightforward process as illustrated by the stepper design. Application Input is all about customer business info, while Decision Input is all about their credit health. The last step is about approving or rejecting recommended decision based on system calculations.
UI Iteration based on user feedback
Once an application has turned into a loan, it becomes the responsibility of the loan team. Because application and loan are not separated in the UI anymore but shown as accounts with different statuses, patterns such as dashboard and application forms are reusable for another usertype, saving the development team a lot of time. Main difference here is in edit vs. view mode.
Read-Only Application View
Expanding the system for merchants
Since accounts encapsulates both application and active loan, the dashboard istransferrable to merchant view as well. However, merchants have the added functionality to see transaction history and make batch charge/credit funds from a customer’s account.
Impact
We launched on time for fall 2020 crop season and our system afforded client to increase revenue by 3X without having to increase headcount.Post-launch: Added a new source of revenue for client. After the successful adoption by merchant, our client were able to collect a small merchant fee for each customer that use this service.
Learnings
- When time is limited, choosing to strategically use ready-made components and building upon it helped greatly in ensuring a working and fast product that is the foundation of good user experience.
- Observing and iteratively soliciting feedback from stakeholders who are also our users enabled us to make sure that they have a good experience with the system.
Whiteboard App is a communication tool to improve the sharing of tactical information between public safety officers by annotating on a sharable live canvas.
2018 • Product Research • Strategy • UX/UI Design • Consultative Support
Background
An enterprise client approached us to research the framework and information architecture of a startup whiteboarding app which they had been planning to acquire. I investigated whether requested feature sets such as drawing on a live map and sharing a canvas with multiple user groups could be integrated into the enterprise client’s existing product suite.
My Role
- Researcher, Analyst, Strategist, and UX/UI designer.
- Collaborated with multiple external teams in enterprise and startup environments to build an acquisition compatibility report in 6 weeks.
- Drafted proposal of redesigned Whiteboard app in the case that the acquisition fits the client’s business goals
- Analyse startup’s app user flows and framework for merge
-
How could this app integrate with existing product in suite?
Part 1 - Investigate userflow and information architecture for compatibility
Startup Model : Inclusive
Single all-in-one app, group centred, sharing can only happen within groups
Single all-in-one app, group centred, sharing can only happen within groups
Enterprise Model : ModularMany apps, task centred, sharing between multiple apps and groups allowed
Our client’s app is designed to be a complete communication app supporting multiple communication tools such as messaging, mapping and file exchange. It is a closed system and does not rely on any other connections or servers etc.
Original UI
Userflow map - high level
After watching demos, testing, conferencing with DForce product owners, and mapping over 100 user flows, I conducted a heuristic evaluation and highlighted major pain points in the userflow:
- Navigation
- Looping navigation patterns make userflows unpredictable and confusing.
- Lack of visible hierarchy resulted in unclear user goals.
- Map & Sharing
- Lack of clear visual cues indicating which group a user is currently viewing.
Eg. Map allows user to see annotations from all groups that they belong in, however, there is no cue indicating which annotation belongs to which group. - Complex accessibility by grouping sharing options under general map tools.
- Nesting
- Lack of breadcrumbs for nested options. Eg. copying a file to another group requires 3 dialogues with no system visibility.
Consulted Recommendation: We suggested not to proceed with acquisition due to the large discrepancy in engineering structure, as well as potential problems integrating to client’s custom product suite. However, if the client wanted to go through with the merge, I proposed to prioritize an app redesign based on identified pain points:
- Creating and revisiting a whiteboard
- Sharing permissions between shared and private whiteboards
- What relevant drawing tools should be available to user?
Part 2 - Redesigning whiteboard UX for merge
Given the complexity of the app, I eliminated redundant features that the client already has, and focused on primary flows to create whiteboard, collaboration and drawing tools.
A. Whiteboard gallery
I restructured the app’s starting point from drawing tools to listing whiteboards in a gallery, which changed the homescreen’s initial focus to whiteboarding only.
I restructured the app’s starting point from drawing tools to listing whiteboards in a gallery, which changed the homescreen’s initial focus to whiteboarding only.
B. Collaborators & Whiteboard
I gave users the choice to start with adding collaborators or drawing on whiteboard, to accommodate for the existence of private and shared whiteboards.
I gave users the choice to start with adding collaborators or drawing on whiteboard, to accommodate for the existence of private and shared whiteboards.
C. Map, Gallery and Camera
By placing map, gallery and camera accessibility after creating a whiteboard, users could flexibly work atop multiple
canvas types.
By placing map, gallery and camera accessibility after creating a whiteboard, users could flexibly work atop multiple
canvas types.
2.1 Creation & Return Flow
2.2 Group Management
Prototyping using Sketch and Craft for Invision
2.3 Whiteboard Drawing Tools
Results
Enterprise client evaluated my recommendations, weighed the significant engineering discrepancy and decided not to acquire startup company due to the large integration efforts that were discovered, saving the enterprise over $500k.
Learnings
- Don’t compromise on UX. In projects involving complex systems, embrace complexity by prioritizing problems and suggesting possible solutions.
- Be humble and willing to ask for clarification with startup’s product team during the research phase to avoid wrong assumptions.
- Always consider what insights and future potential could be offered to the outsider/next project owner from a UX analysis. How can we make our design clearer and better for the person continuing it?
*To comply with my non-disclosure agreement, I have omitted and obfuscated confidential information in this case study.
Zebra Data Visualization Guidelines is part of Zebra’s visual language for industrial use. It aims to bring consistency, simplicity and flexibility to product and engineering teams across enterprise systems
2017 • Creative Direction • Visual Design • Guideline Writing
The Brief
Zebra approached us to write and design a data visualisation guide for their internal Design System. We followed existing brand guidelines by the request of our client.
My Role
- Creative direction, Visual design and co-writer with a UX professional.
- Collaboratively researched and wrote data visualisation best practices.
- Visualised all charts and prepared components for build.
Surveying developer needs
Working with a UX manager and writer to expand data visualization arm of Zebra’s new design system. We collaboratively researched common charts used across Zebra’s product offerings, distilled them into 8 chart types, and recommended how to use a chart effectively by suggesting a story or data based approach. After identifying chart types, we expanded each type into different configurations using Adobe Illustrator.
Writing a useful data visualization guide
Enterprise users work with large and varying data sets, oftentimes in the form of spreadsheets. They needed to determine what charts are appropriate based on the specific data set on hand. I looked at Google’s Material Design for format inspiration and gave brief introductions to each chart type outlining the pros, cons and recommended use with each data sets. Configurations are illustrated for each type chart that engineers could use with varying data sets.
Impact
Zebra’s engineers found guideline and preset visuals useful to increase focus on building functionality while efficiently adhering to consistent brand guidelines.
Learning
All in the details: One of the main reasons for inconsistent visuals was approximating/eyeballing details such as color, line thickness, typography and icons. By defining a standard and providing values in CSS, users were able to quickly access and adapt to our data visualisation language.Let’s work together 👩🏻💻 💪
︎ josephine.rahadi@gmail.com
︎ Download my resume
(c) 2023 Josephine Rahadi