Zarya Faraj

Welcome to my portfolio! I specialize in end-to-end product design, which includes UX, prototyping and visual design.

Chain Core Dashboard

Chain Core Dashboard

Real time Blockchain visibility that helps software developers learn, experiment and build prototypes for their organization. 

To maintain confidentiality of users and customers, I am unable to publicly release personas. 


Blockchain is an emerging technology with a lot of promise for the financial industry and a high barrier to entry. 

Developers usually begin learning about Blockchain in the context of Bitcoin (the currency), which involves a decentralized network that is not applicable to the closed network required by Chain's customers (banks, asset managers, and issuers). They then spend a lot of time rebuilding the infrastructure without deep knowledge of foundational subjects, like cryptography. What's more, a lot of effort is put into the development of tools for configuring their Blockchain network and accessing the ledger data.


 I designed Chain's Sandbox Dashboard in 2016, and it served our customers for over a year before we pivoted and had to build our new product, Chain Core, from the group up. 

I designed Chain's Sandbox Dashboard in 2016, and it served our customers for over a year before we pivoted and had to build our new product, Chain Core, from the group up. 

To test out the viability of and need for a specialized Blockchain for the financial industry, Chain's primary offering for a year was a Blockchain Dashboard that operated in a sandbox environment, so access to the dashboard was limited to paid customers and the capabilities were bare-bones.  

During that year, the team used the Dashboard to build over 20 partner and 6 internal applications. In that process, we validated our assumptions about users’ needs and discovered significant gaps in meeting those needs. 


In 2016, our team was tasked to build Chain Core, which includes the Dashboard, Documentation, SDK, and APIs. Our goal in building the Chain Core Dashboard (aka Blockchain interface for the financial industry) was to enable developers to build blockchain applications more quickly by reducing their knowledge gap and eliminating the time spent developing internal tools for standard tasks.

We hypothesized that we would see increased adoption, less time spent on redundant work, and immediate access to Blockchain ledger data. We had a very tight 2-month timeline to solve these issues before a major launch at a large financial conference. 

 Our vision could be synthesized into four major values.


User & Audience 

The primary users of the Chain Core Dashboard are software developers and technical product managers in a large financial institution like Visa and Nasdaq. They are usually part of an experimental team within the organization that is asked to build innovative blockchain solutions while working on multiple value-add and unrelated projects. A secondary set of users are independent developers who are more proficient in Blockchain and contribute to the open-source Chain Core technology. 

Fintech developers use Chain Core not because they are enthusiastic about the technology, as independent developers generally are. Instead, they have a very defined set of tasks that they need to accomplish as part of their application development and are relying on the Dashboard to get real-time access to Blockchain data. Technical product managers, on the other hand, take on a more exploratory role as they are usually responsible for the inception and demo of prototype ideas. 

Increasing the complexity of these users is that their needs vary across industries, Blockchain expertise, and stages of a project. Identifying and solving for the standard task flows across these user groups was one of the most challenging design efforts for the Dashboard. 

Team & Stakeholders 


I met regularly with our cross-functional team with representation from product, engineering, product architecture, and business. I relied on this group for reaching alignment on our goals and success criteria, getting feedback on critical features, and sharing impact of the designs on user behavior. At an oversight level, we also had to gain alignment from our CPO (Chief of Product) and CTO (Chief of Engineering) on the product direction. Each week, I presented my designs to the team before the work was handed to our Product Engineer for development. 

Product Team

I worked in a small product team, consisting of a Product Manager, Product Engineer, and myself as the Product Designer. This was a very agile project in which some level of research and prioritization was conducted initially, with the majority of the discovery, research, and design occurring during each sprint. As features were delivered, we integrated them into the overall product, tested our hypotheses, and then made changes accordingly. Our weekly product planning meetings became critical to ensuring that we were all moving in the same direction, instead of getting lost in delivering features. 


While designing the Dashboard experience, I was also working on projects with customers that required the use of the Dashboard. These projects served as a way to validate our decisions and get more feedback on what was or wasn't working in their current workflow. 


Small team building multiple projects under a tight timeline

We had two months to build a functional dashboard for a complex workflow with just one engineer and designer. Individually, we were also experiencing the pain of context-switching between multiple unrelated projects.

Luckily, our Dashboard scope was well-defined and our weekly product planning meetings were integral to sharing progress and adjusting our scope. After each major sprint, we also did an internal demo to identify bugs and gaps in the user experience. Such proactiveness about our progress and team alignment helped us meet our deadline and leave over 2 weeks for user testing. 

Creating a consistent experience across web and OS 

One of the critical challenges of designing a software for enterprises and independent developers is accommodating their specific technology needs. We had to maintain feature parity between operating systems, and responsiveness between web browsers.

Examples: 1) the application icon and loading screens on Mac and Windows had to adhere to a different set of guidelines 2) lots of bug fixes to make forms and typography consistent between IE, Firefox, and Chrome. During testing, I put my HTML and CSS into good use. 

Design Process

First-time user experience

A key consideration in the usability of the dashboard was the blockchain setup process and getting users to task completion as quickly as possible. 

 Configuration options for Chain Core

In setting up the dashboard, it was important to make the available options understandable and easily configurable. For example, the order of the configuration options was dictated by our users' needs. The vast majority of our enterprise customers were fairly new to the technology and likely create a new blockchain network. A second group of customers were large financial firms with a greater degree of experience with blockchain and with a desire to join an existing network. Lastly, we had a third option for browsers and independent developers interested in our technology but still uncertain about its value and utility. 

Once users completed the basic setup, I needed to address how to introduce them to the value of the Dashboard: complete tasks with much greater speed, accuracy,  and ease than doing so programmatically. As such, one of the earliest iterations of the tutorial was showing a side-by-side comparison of the programmatic and Dashboard processes, using the 5-minute guide published in the Chain Core Documentation.

The options ranged from 1) providing the tutorial before users entered the dashboard 2) a step-by-step guided tutorial using in-context tooltips  3) a separate tutorial page that could be visited anytime. 

The design option involving tooltips was aimed at constraining the user to perform the current step. However, our users are developers who like to read through documentation and then perform actions. Thus, the off-side tutorial was most fitting with their current workflow. 

After weeks of testing, feedback and iterations, I landed on a design that contextualized the 5-minute tutorial into the dashboard views. The steps were broken down into Learn, Do, Review, and in a different color to distinguish it from the dashboard elements. 

 The final design was contextualizing the 5-minute guide from the Developer Docs into the Dashboard flow. 

The final design was contextualizing the 5-minute guide from the Developer Docs into the Dashboard flow. 

Create blockchain transactions

By the time the Dashboard project was started, the Engineering team had already developed one of the main functions of our Blockchain technology, specifically, creating a transaction programmatically. They designed it such that a transaction could be created using a combination of actions.  I had to stick to this flow to ensure that developers had a consistent experience between the programmatic and interface options,  and to avoid impacting our already tight project timeline. So my goal was to make actions an understandable and easy way to create a transaction using the dashboard.  

With that goal in mind and after many iterations, I designed a simple form in which  users could add actions consisting of a few required and optional fields. To provide guidance and limit information overload, I made a few adjustments to the form: 

  • Prior to adding any actions, users are provided an empty state message with a link to the Transactions Basics section in the Developer Documentation
  • Reference Data fields and advanced options are toggled because our hypothesis was that they wouldn't be used often
 Basic transaction form in which users could create a transaction with a set of actions

Basic transaction form in which users could create a transaction with a set of actions

The complexity of creating a blockchain transaction could be compared to the process of filling out one's taxes, in that one decision can create multiple new paths or steps. With more time and a larger user group for testing, I would have experimented with a game-like flow, in which this multi-step and error-prone task is made easy with the system performing the logic and providing the necessary validations along the way.

View data

One of the most fun design challenges involved making complex data sets readable, consumable and actionable. The key issue was to present the right information depth at the right time.

 Transaction activity view. Links indicate that users can click to view more details (e.g. asset Gold). 

Transaction activity view. Links indicate that users can click to view more details (e.g. asset Gold). 

  • Did the transaction I just submitted go through? At the highest level, a user needs to see the activity of transactions with the most recent transaction listed first. 
  • Was the transaction submitted correctly? A user needs to have enough information (action type, amount, asset and account, ID and time) to determine whether the activity data matches what they provided when creating the transaction. 
  • How does this transaction look on the blockchain? A user needs to view a specific transaction with all the input and output details, whether that's in a readable table format or in raw JSON for backup and validation. 
 Single transaction view.  I  first duplicated the summary table from the Transactions activity view so users knew they were looking at the same transaction before diving into the details.

Single transaction view.  I  first duplicated the summary table from the Transactions activity view so users knew they were looking at the same transaction before diving into the details.

Breaking down a JSON into 2+  columns increased the perceived complexity of the data. Whereas part-table/part-JSON was a middle path that increased readability without disrupting the mental model of developers. 

Query the Blockchain

In dealing with large datasets, users either browse in order to validate data accuracy and identify any anomalies, or they know exactly what they were looking for and need a way to search. In creating the Dashboard search experience, there were two approaches that were explored.

On one hand, the experience could prioritize non-power-users: options constrained to what's available, use of simple human language, and real-time data validation of fields. This is the method I preferred and hypothesized would result in lower errors and a shorter learning curve. 

 A friendly search option for dashboard

Separately, the engineering team had already built out a query language for Chain Core. We ultimately opted for a basic search for v1 of the Dashboard that utilized our existing query language  because:

  1.  developers could avoid learning two different methods for searching (programmatic vs. human language)
  2. we could at least have a functional search feature instead of an unfinished one by the release date

In this design, users can query the Balances by typing parameters into the search field, and then add additional filters by clicking the set sum_by button. Validation of the query parameters are done after submitting, and users are given an alert with some direction on correcting the error. 

 First-time users are prompted to visit the Documentation to learn about the query parameters before searching the blockchain. 

First-time users are prompted to visit the Documentation to learn about the query parameters before searching the blockchain. 

Visual Design

In parallel with the UX and data design of the Dashboard, I was also leading the UI and visual design, which included: 

  • Creating a set of reusable components 
  • Designing vector icons for the navigation and configuration views, and Mac/Windows app loading pages
  • Using the brand typography for presenting blockchain and network data 
  • Reusing Chain colors when possible to create a consistent experience, but adding to that scheme for readability of data
 Visual design library for Dashboard

Once detailed high-fidelity specs were completed, I would import them into Zeplin for our developer to use. Often times, I would add contextual comments to communicate expected behavior. Doing so was a cost-effective and simple way to communicate designs, provide design assets, and build out design specifications. 

 Dashboard specs provided to developer in Zeplin 

The Result

Chain Core Dashboard is now supporting large companies like Nasdaq and Visa with a web, Mac, Windows, and Linux app that provides a central place for developers and product managers to experiment with a blockchain network, view real-time transaction data, and build prototypes.  


Product before Engineering

Since the Dashboard project was kicked off after the underlying technology and programmatic tools had already been built out, the Product team's innovation arm was somewhat constrained for v1. When it came to value propositions like searching the blockchain, for example, we could have built out an incredibly powerful search tool with a low barrier to entry. Instead, users search via a complex query language and thus rely substantially on our documentation for directions and error corrections.

Given how inextricably tied the various Chain Core products are, Product and Engineering efforts need to be more time-aligned going forward, each informing the other. 

Investing in user research

Due to a tight timeline and a limited enterprise user group, there was a danger of building the Dashboard for power-users and being over-reliant on our ingrained knowledge. 

With no time allocated for user research, I depended heavily on informal guerrilla user studies with developers within and outside the company, informal feedback sessions with current customers, and ad-hoc Dashboard demos. A formal investment in user research as a design process and role is still needed.  

Analytics for validating design 

Having quantitative data would have helped me validate my design decisions, choose between multiple design directions, and reduce the risk of biased results from self-reported task completion rates. Since our project timeline was so tight, we were not able to setup analytics into the Dashboard before we launched. Afterward, I proposed an analytics initiative that included the questions to be answered and the tool with which to analyze that data. As a result, the engineering team was able to add some basic metrics into the next releases, with a goal to establish a formal and long-term process for analytics. 

Consumer Payments

Consumer Payments