Debbie Pan

Dappest

Product Designer | July 2018 - Present

Dappest is a website that our team (a core group of 2 developers, 2 designers, and some supporting members) designed to provide a place where users can discover and write reviews for decentralized apps (DApps), while DApp developers can gain visibility for their DApps and receive feedback from the community. Our mission is to provide a transparent and helpful online platform, where people can easily find trustworthy DApps that can be utilized for every day purposes so people can equip themselves with the tools to improve their lives, empower themselves, and be in charge of their own future.

Problem

There are a couple problems we are trying to solve, such as:
How do we make decentralized apps more friendly and accessible to everyone, especially when people don’t trust this technology?
How do we help existing users find information that provides value and contributes to their decision to use a new DApp?

My Role & Process

I lead the creative direction and designed the flow and look and feel of the interface. I first started out by figuring out what the vision the CEO of our product had and what look and feel he wanted to go for. I had him fill out a creative brief, and found that he wanted our brand voice to be welcoming, trustworthy and simple.

My responsibilities included:

Establishing a design process and advocating for UX to be present at every stage
Visual Design / Look & Feel / Styleguide
Ensuring the design matched with our branding
Writing questions to ask users
Creating personas and use cases
Product roadmap
Wireframes
UI Design
Strategy / Ideas for the product such as how to incentivize people to leave reviews
Minimum Delightful Product
Content writing & Micro-copy

Discovery

We did some market research to see who the users of currently existing sites are and we found that there are three distinct personas: the existing DApp user, the new user who is trying to get into DApps, and the DApp developer. In talking to these users, we found that there was a need for a site that provided better information from the community about DApps.
Research

We did a competitive analysis on other sites such as Dapp.com, State of the Dapps, etc. and highlighted the strengths and weaknesses of all of them, as well as analyzed their business model. This allowed us to see what they were doing well, what they weren’t doing as well, and what we could try and incorporate into our site. What we found was that although there were similar sites, they were either too stat-heavy and didn’t make sense to new users (and sometimes even existing users) or they didn’t provide enough user-generated information about the DApps for it to be useful.
Task Analysis

We identified the goals of each persona by asking questions such as “Tell me about the last time you were looking for a DApp to use. Did you find one? Why or why not?” Or “why do you read reviews?” Asking follow up questions proved useful and helped us get to the main motivation. In this case it was that they wanted to find out what was negative about the product and whether there were things they needed to be careful of, and because we knew the why, we were able to account for it in our design.
Sketch It Out

I would sketch out a proposed flow, then present it to the team to get feedback and see if there were any technological constraints or gaps in the user flow before creating a wireframe for it.
Low-Fidelity Wireframes

Because they had already started coding it and we had a deadline of October 1, we came to a solution of making medium fidelity wireframes on Sketch and uploading to Invision - that way we didn’t necessarily have to worry as much about the colors, but we had a very basic look and feel down and the front-end dev would have something more to work with instead of basic boxes. This way, when he translated it to high fidelity, he would only really have to put in images and colors, as we were going for a minimum delightful product.
Test & Evaluate

We talked to users and had them walk through our quick and dirty Invision prototype, and incorporated their feedback into our next round. Some of the flows we made changes to were the onboarding for how to install MetaMask, and the information architecture of the Individual DApp page.
High-Fidelity Mockups & Prototypes

We established colors and the style of graphics for the site and from there I was able to create a style guide (albeit a messy one as we were short on time - I still need to go and clean this up) and finally put in all the styling.
Delivery!

Everything was put into Zeplin and I worked closely with the front-end developer to ensure implementation went smoothly.
Refinement

We were able to fit in some QA, but definitely not as much as we liked. We prioritized the critical bugs that we observed, and are working on addressing the others.

Challenges & Lessons Learned

We had to iron out some team dynamics in the beginning because we had never worked together with each other, so it was about finding a good working style. There were also some miscommunications, but we were able to resolve these through communicating and trying to understand where the other was coming from. I learned a lot about defending my design decisions, as I had to push for certain features to stay on the site such as the optional section of the Write a Review modal by asking how the user would be impacted by this decision and bringing it back to the business goals. We also ran out of time and were not able to do as much QA as we would have liked, which lead to some broken experiences. Now we know to try to plan better for next time, as this all plays into the experience a user has with our product. We did our best to smooth things over in a friendly and transparent way by communicating how we are still working out some kinks since we just launched, and telling them that we appreciated their patience and feedback because it helps us improve and create better experiences for others.

Results

We launched on October 1st and we got around 15 DApp submissions! This didn’t quite reach our goal of 30 DApp submissions, but we are still undergoing the efforts of emailing developers and increasing our social presence through blog posts, among other things.

Next Steps

Next steps would be continuing to QA and fix the bugs. We also need to make it mobile friendly to comply with Google’s search engine standards and include Google Analytics to our site so that we can start measuring metrics such as time spent on each page and the most visited pages. Another thing we need to do is optimize for SEO and look into marketing tools like heat mapping and eye tracking. There are also features that we still need to finish and test out on users to see if it is intuitive. So, in short, THE LIST IS NEVER ENDING. But it’s been a fun process and I’ve enjoyed working with this team, and I'm really looking forward to seeing what we more we can accomplish!

AVERT

Pacific Science & Engineering

Lead Designer | June 2016 - June 2018

AVERT is a spin-off of CaSHMI. The two are closely related; however, AVERT is in a sense, future state CaSHMI. AVERT is a R&D product that mainly deals with anomaly management at a mission level and helping reduce cognitive load for an operator monitoring many unmanned vehicles at once and in other complex automated systems. Due to the sensitive nature of the project, I am not allowed to share any detailed photos of the actual interface.

Problem

Currently, only legacy data-level displays unique to each vehicle exist with imprecise alerts, which limits in scaling to future Department of Defense vision. The advanced automation technology that is available is not reliably evaluated, which is a problem for the operator as this means they get incomplete situation awareness.

My Role & Process

As the lead designer, I analyzed the problems and requirements, and came up with an initial design that we have since iterated on and coded into a prototype.

Discovery

To start, we needed to figure out what information is priority for the operators. Where does the Mini-Dash live, and when would this type of anomaly management be useful? Are there certain limitations for this product?
Research

I did some research into what technologies currently exist, and used Dribbble to look up examples of alerting methods and dashboards.
Task Analysis

By analyzing the current information the operators look at today, we found that one important thing they look at is the bingo/ joker time, which tells the operator at what point they need to move on in their mission to be able to have enough fuel for the rest of their ops. We also needed a way for the user to be notified when there is a notification, warning, or alert that pertains to the vehicle.
Sketch It Out

To get some initial concepts down, I sketched out a couple of options and brought them to a design meeting to share with the team. From there, we discussed what features we might want, such as a timeline, and which we might not want, like the number of missiles.
Low-Fidelity Wireframes

I used Photoshop to lay out the bare bones of the information architecture.
Test & Evaluate

We did some internal testing of the prototype to see if it made sense and conveyed the right information, such as whether a loss of link was salient enough to the user. We also found a couple of scenarios that we needed designs for, like the interaction for when a vehicle crashes. The design has definitely come a long way, and we are constantly adding features.
High-Fidelity Mockups & Prototypes

I originally used Illustrator to create the mockups, but I recently moved to Sketch. The symbols and global styles help a lot when we add functionalities to the design. However, I still maintain a file in Illustrator for the prototype that we are implementing.
Delivery!

I helped with the creation of briefs detailing the scope of our project and the progress we have made so far. This was presented to the program manager for feedback.
Refinement

As we tested the prototype, we realized that we also needed to add some sort of alert log for the user to keep track of past alerts. This is currently where we are with the design, but I'm sure there will be more features we need to add as the design matures.

Results

We are in the experimentation phase right now, so we have been getting the prototype ready and doing QA and smoothing out interactions within. Our goals for the experimentation are to develop validation, and figure out what the tradeoff is between mission complexity and benefits of Mini-Dash elements, as well as how the Mini-Dash impacts the operator’s anomaly management approach.

Autonomous Vehicle Interface

Pacific Science & Engineering

Co-Designer | June 2016 - June 2018

This is an enterprise application that we developed to help the military manage and monitor autonomous systems. Due to the sensitive nature of this project, I am not allowed to share the screens or give too much detailed information about the project.

Problem

The current programs used by the operators only allowed for control of a single autonomous vehicle at a time, which was incredibly inefficient. Therefore, the main goals we wanted to achieve was enabling mission-level task management and allowing a single operator to control multiple at a time. The interface also needed to be responsive to be adaptable to all sorts of screen sizes. The measures of success were if the operators were successfully able to create tasks for individual vehicles in each mission, and if it took less time to do than the legacy systems.

My Role & Process

As this is a big project, the team comprised of 2 designers and a couple of cognitive scientists. I joined the team halfway through the project, when I first started at PSE. We divided up the interface into sections and each designer was responsible for working on certain parts of the interface. I worked on the Mini-Dash, Geo, and Detailed Status sections of the interface.

Discovery

What was the environment the operators worked in? What was the language that was familiar to them? To answer these questions, we relied on our Subject Matter Experts (SMEs) to guide us.
Research

We would also look in documents and manuals to figure out the currently used controls or terms the operators were used to. When designing certain components, we would look to real world examples and see what other applications did.
Task Analysis

Writing out the process the operators use currently helped us figure out how to improve the functionalities being added. We did a lot of analysis on the current
Sketch It Out

Before mocking it up, I would bring my ideas sketched on a piece of paper or draw it on the whiteboard for the team to discuss. I did this when we were trying to figure out how to rearrange a certain component.
Test & Evaluate

We put it through some intuitiveness testing in early December at a particular event, where operators were given a quick overview of the program and then observed. We also observed users during demos as well.
High-Fidelity Mockups & Prototypes

We worked closely with a team of off-site developers. We mainly used JIRA and screenshots with descriptions to communicate our ideas.
Delivery!

Recently, we delivered the User Guide and the Functional Description Document to help users and future developers understand the software and our design intents.
Refinement

We observed some bugs at Step 3 testing, so we are waiting for those to be fixed.

Challenges

Because of security clearance issues, it was hard to gain access to users, so we had to rely on SMEs heavily to provide guidance. A big barrier to entry was the domain specific knowledge required for the design, as well as getting familiarized with the current processes. Many times, there was a big gap in the user base - there were those that had been using the systems for a long time and were resistant to too much change, and younger navy personnel who were more up to speed and expected easier to use products. Finding a balance between the two was difficult, but we were able to introduce similar processes for certain tasks such as creating a route on the Geo, but grouped in a way that made better sense in terms of user experience. Therefore, a lot of analysis of the current existing applications was needed. We also ran into some difficulties with the developers not having enough time to implement our recommendations, as a lot of their time was spent on debugging and ensuring the system ran smoothly. To resolve this issue, I lead both our teams in an empathy mapping exercise to create a better sense of understanding of the goals of each team and see how we could work together as one unit to provide a delightful design for the users and meet the deadlines set by the program director overseeing the process.

Results

Currently we are waiting to implement this program in the respective control stations. In the next phase of the project, we will be working with to adapt this program for other purposes.

iNavy

Pacific Science & Engineering

Designer | 1 month

iNavy was one of the first projects I worked on when I first started at Pacific Science & Engineering. It was a very quick project where they just wanted some style guidance for their website redesign, so that was what we provided for them.

Problem

The current iNavy website is outdated and not aesthetically pleasing - there are random colors used in the text and clipart icons. A lot of the copy used in the site was also confusing to the users.

My Role & Process

Since this was a quick project, I mostly worked with the program officers and other teammates to provide the styleguide and recommendations for the updated website.

Discovery

What were they looking for? How much of the website could we redesign, and what did they want us to leave alone? We found that they wanted to keep most of the information architecture the same, but if we saw anything glaringly inconvenient for the users, we could provide the recommendation to change it.
Research

I looked on Dribbble and found examples of landing pages that I liked and put them in a folder so that I could quickly access them later when designing.
Low-Fidelity Wireframes

We used Balsamiq to lay out the most important information and figure out what we wanted to keep and what we wanted to take out.
High-Fidelity Mockups & Prototypes

I then used Sketch to lay out some header styles and a color palette. Then I created two different home page options and presented them to the team to see which one we wanted to move forward with. Once they chose the design, I went on and redesigned the Training page and Support Center page as well, just to show the layout of the child pages.
Delivery!

The final product was 3 different splash page options, a quick, general styleguide (pictured below), and a redesigned home page (pictured above), Training page (pictured below), and Support Center page.

Results

We presented the two options to the Navy program office and it was well received. We were unable to follow up much since we only had funding for that one month.

HMS

American Specialty Health

Designer | 4 months

HMS, or Healthyroads Management System, is an internal system tool we created to help product managers and clients customize the landing page for the users of Healthyroads.

Problem

As the company’s products were expanding, the developers’ workload also increased. One big investment of their time was in creating landing pages for new clients of our health benefits program, so to take some load off the developers, we needed a tool that would allow product managers to directly create the landing page from pre-set templates with minimal involvement from the developers.

My Role & Process

There were two other designers and one information architect also working on this product. I worked on the concept for displaying how to convey what was being customized and helped in the ideation process. However, I did not stay until the end of the project as I started a new job before the final delivery.

Discovery

The first step we took was trying to determine the information the project managers and clients would customize. We realized that there were different levels of customization, based on the package the clients bought.
Research

After getting a general sense for what the requirements were, we figured we should create a website customization system, similar to Weebly or Squarespace. Therefore, that was where we started. We looked at what components each of those sites had and did a competitive analysis.
Task Analysis

We mapped out the product manager's process from when they first received a new client to creating the end product. They first receive a paper with categories, in which the client specifies what changes and text they want in the site. This is then given to the developers to work off of. The paper gave us a lot of good insight as to what components we needed to include.
Low-Fidelity Wireframes

Low-fidelity wireframes were laid out to help us figure out the flow of the different tasks within the customization site, such as the image upload.
High-Fidelity Mockups & Prototypes

We used Photoshop to create the mockups, and After Effects to create a gif that showed the kind of interaction we wanted the front-end devs to implement. It was a quick and easy way for us to communicate with them, and they knew exactly how we wanted things to work.

Results

The tool that we created is similar to Wordpress or Wix - sites that have templates available for the user to quickly create a website, with editable fields for customization. From what I hear, HMS is still constantly being updated, but it helps a lot with reducing the workload for developers so that they can focus on other projects.

Crumboard

Seamgen

User Experience Lead | 1 month

Crumboard is a fully integrated project planning and management software tool that we built for our own internal use.

Problem

Currently, we use Mavenlink and JIRA to plan and manage our projects. Both of these products have pros and cons, and going back and forth between the two made our process more inefficient than we felt it needed to be. Therefore, we wanted to create our own tool that combined the best parts of each product to consolidate and streamline our process.

My Role & Process

The project had been started a while back, but never completely finished. I was tasked to go in and organize all the half-baked ideas into a workflow that made sense, and to make the interface look sleek so that we could present it to potential investors. The main components I concentrated on and refined were the Creating an Estimate workflow and the information displayed on the Dashboard tab, as well as starting the Add New Story workflow.

Some of the whiteboarding sessions that we did

Discovery

The primary users of this product would be the project managers and upper level management. They shared a lot of the documents that they use currently, and we discussed what their needs were - to have a tool that could automate creating an estimate and easily convert it into a project.
Research

Now it was time to dig down deep. I referenced JIRA and Mavenlink a lot to get a sense for their pros and cons and decide which features would be worth carrying over, and which weren't as efficient.I went on Dribbble to get inspiration as well.
Task Analysis

What is the process that they use right now? I found that they used a combination of Google Sheets and Google Docs to create their current estimates, then manually input everything into JIRA. From there, I created a preliminary user flow depicting what I thought the process should be based on my findings and to help get the ball rolling on the designs.
Sketch It Out

A lot of whiteboarding sessions took place, and I filled my notebook with sketches of the different layout options. This helps me visualize the requirements on the page itself, and I'm able to explore different avenues and scrap versions quickly without wasting too much time digitizing it.
High-Fidelity Mockups & Prototypes

Since we already had an established look and feel, and because we were on a tight timeline, I had to go straight to high-fidelity mockups from my sketches. These mockups were created in Sketch, and uploaded to Invision for easy project collaboration and feedback.
Test & Evaluate

We had our CEO and some project managers go through the screens in Invision, and observed which features made sense to them and which didn't. We then made some adjustments to the designs and added new functionalities.
Delivery!

I uploaded the screens into Zeplin for the developers to build out.

Challenges

We were on a tight timeline because we wanted to present the product to potential investors - so it was difficult staying true to the process and not blindly designing. It took a significant effort, but ultimately I was able to talk to the project managers (the end users of the estimation workflow) and test out the screens I designed to iron out the kinks.

Results

Crumboard is still currently undergoing development, with many new features being added such as integration with Skype and Slack for improved inter-team communication.

America's Pharmacy

Seamgen

User Experience Lead (creating supporting pages) | 1 month

Prescription drugs cost a lot. Almost half of US residents have reported trouble paying for their prescriptions, and a quarter report going with prescriptions because they simply cannot afford the cost (source: Kaiser Family Foundation). In fact, the number one reason Americans don’t take the medication they are as prescribed is cost of that medication. America’s Pharmacy is a prescription drug savings program that is designed to help users save up to 81% on both brand name and generic prescriptions.

America's Pharmacy Homepage

My Role & Process

We worked closely with their development team to provide a homepage redesign and supporting pages, such as a pharmacy locator and mobile-friendly savings card/coupons. Users can easily search for their medications, find the best price, and take their coupons or savings cards to their pharmacist to get great savings on much-needed medications. The styleguide was already established when I came onto this project, so I created some additional supporting pages such as the coupon / cash card workflow, mobile appstore and blog pages.

Cash Card | Desktop & Mobile

The clients wanted to move from a digital cash card to a physical one so that they have the users' addresses on file. However, since most people would prefer a digital one, the primary form asks for their email address. Underneath is an option that allows the user to check "Send me a physical card as well". If the user checks this box, the form expands to ask for their mailing address. The third screen is a confirmation with other options if the user wants their card in another format too.

Cash Card desktop workflow

Cash Card mobile workflow

How It Works

The purpose of this page is mainly for SEO purposes, and for the user to get a quick and easy-to-digest overview of how this service works.

How America's Pharmacy works

Mobile App

Eventually, there will be a mobile app version of this site, so the clients wanted a page that could advertise their app.

As user scrolls down the page, different features of the app will be highlighted

Search Results

This was a redesign of an existing page to add some functionalities. Occasionally, different pharmacies will have different prices, so we needed a way to indicate that. They also wanted to group pharmacies with the same name and hide the locations until further action is taken.

Map with addresses can be shown or hidden with a click

Debbie Pan

Interaction Designer

01

About
Me

02

My
Process

Discovery

Research

Task Analysis

Sketch It Out!

Low-Fidelity Wireframes

Test & Evaluate

High-Fidelity
Mockups & Prototypes

Delivery!

Refinement

03

My
Projects

04

My
Experience

Product Designer, Enterprise UI/UX

ServiceTitan

User Experience Lead, UX Designer (Contract)

Seamgen, Jack-in-the-Box

Interaction Designer

Pacific Science & Engineering

Jr. Interaction Designer

American Specialty Health

Debbie Pan

Interaction Designer

01

About Me

02

My Process

Discovery

Research

Task Analysis

Sketch It Out!

Low-Fidelity Wireframes

Test & Evaluate

High-Fidelity Mockups & Prototypes

Delivery!

Refinement

03

My Projects

04

My Experience

Product Designer, Enterprise UI/UX

ServiceTitan

User Experience Lead, UX Designer (Contract)

Seamgen, Jack-in-the-Box

Interaction Designer

Pacific Science & Engineering

Jr. Interaction Designer

American Specialty Health

Dappest

Product Designer | July 2018 - Present

Problem

My Role & Process

Challenges & Lessons Learned

Results

Next Steps

AVERT

Pacific Science & Engineering

Lead Designer | June 2016 - June 2018

Problem

My Role & Process

Results

Autonomous Vehicle Interface

Pacific Science & Engineering

Co-Designer | June 2016 - June 2018

Problem

My Role & Process

Challenges

Results

iNavy

Pacific Science & Engineering

Designer | 1 month

Problem

My Role & Process

Results

HMS

American Specialty Health

Designer | 4 months

Problem

My Role & Process

Results

E-Coaching Classes

American Specialty Health

Motion Graphics Designer | ~2 weeks each

Silver&Fit Healthy Aging Intro

Getting Active: A How-To Guide for Beginners

How to Control Calories and Portions

Crumboard

Seamgen

User Experience Lead | 1 month

Problem

My Role & Process

Challenges

Results

America's Pharmacy

Seamgen

User Experience Lead (creating supporting pages) | 1 month

My Role & Process

Cash Card | Desktop & Mobile

How It Works

Mobile App

Search Results

About
Me

My
Process

High-Fidelity
Mockups & Prototypes

My
Projects

My
Experience