2019 - Present
Designer (UX, UI)
Honeycomb is a service created by CLC Group, "a blockchain lab focused on developing real-world connected smart contract solutions for a more trustless, efficient, and secure future." Honeycomb connects three groups of people (API providers, Chainlink oracles, and smart contract developers) in a platform where mutually beneficial partnerships can be formed. API Providers create listings that offer data to oracles, who in turn feed the data into contracts created by smart contract developers. I designed the site information architecture, wireframes, interactive prototypes, and user tests.
Smart contract developers need to be able to build their contracts with easy access to Chainlink oracles. The oracles need to have access to a wide array of data listings, and API providers need to be able to see information about their listings. Such a service does not exist, bringing about the following challenges:
Keeping the learning curve as low as possible for a new technology
Clear navigation as to where the user is at all times
Clarity when there are multiple parameters to select
Flexibility to allow for growing features
Showing all the data on the dashboard while highlighting the most important values
Showing all data without overcrowding
As a startup, our budget is near nonexistent. Thus, all decisions must also make sense financially. While our team is diverse, I fill in for all design roles with the exception of graphic designer (... I know my weaknesses). Almost everyone on the team is international, thus limiting face-time. When I began this project, I did not know anything about cryptocurrency, resulting in a huge learning curve. Last but not least, our timeline and deadlines were very strict as the product release date was strategically picked.
Chainlink is a decentralized oracle network that launched in May of 2019. The network is the first of its kind, as is our marketplace. This unique situation caused us to have no users or competition to study. Thus, most of our user research was pushed till after our service was launched.
To start, I sent everyone a template to fill out their desired features and functions, organized into "needs," "wants," and "desired, but may not be possible." I then scheduled a video call, where we discussed each response and whittled it down to a set list that we further sorted by priority, and whether it was something I would have a hand in.
The resulting features and functions were combined into a low-fi IA map.
Once the features were implemented, a site map was created.
Connecting to an endpoint can feel like an arduous process. You have to see all of the API's endpoints, which are basically doors to open communication with the data, see all the prices, select a network and data type, and take the information received to plug in somewhere else. Since this feature is the essence of the marketplace, it is extremely important to make it as simple as possible.
The design I created aimed to organize the information as logically as possible and in a way that the user has everything they need, with no more and no less. Each step of the connection process was split into a modal (the easiest and fastest way to receive the necessary information), which everything easy to read.
By this point, we were ready to begin work on the API Provider Dashboard. Here, we faced a few huge challenges.
1. Displaying all of the important information at the same time.
2. Allowing the user to see all data while highlighting the most important data.
Thus, with our data scientist, I came up with the concept of "smart view." When "smart view" is turned on, only the categories that make up most of the information is displayed. Anything with a long tail of very low value is effectively excluded. When "smart view" is off, the tail is included and thus none of the data is lost. For example, when "smart view" is on, and only 5 out of the 50 endpoints make up most of the revenue, only those endpoints are visible. If "smart view" is turned off, the remaining 45 low value endpoints are also visible.
As a new technology, I know that users will get frustrated with our service. Thus, I wanted to make sure that when something does go wrong, they have the best experience possible. I made all possible error pages making sure that I not only gave the user an option to navigate elsewhere, but also caused them to break a smile a feel a bit more connected to the staff behind the site. We entertained several ideas, but settled on each of our higher-ups drawing bees (since our product is Honeycomb... get it?) to decorate the pages.
Our audience is very niche, and we had no way to contact the appropriate users until recently. In the meantime, a high-fi wireframe was used to constantly run tests on those in the company not related to the physical development of Honeycomb. I asked them to record their screens while narrating their thoughts as they completed specific tasks. I took their feedback into account while making decisions and changing the wireframe. We also received feedback from meetings with clients (where I was not present), and implemented those changes as well.
I am currently in the process of doing our first batch of official user tests. These tests are being done via video calls, where the users' screens and responses are recorded as they complete several tasks and questions leading to a SUS score to dictate our next moves. I look forward to what I can learn from these conversations.
This whole experience has taught me how important it is to have very open and continuous communication. The amount of research required for the project has been an immense undertaking— one that I am very proud of accomplishing. It has also shown me that no matter the business, the users have similar needs and want to have a smoother experience. It has also been extremely rewarding to see how users are responding to my work. I absolutely love being able to work directly with users and both watch and hear how they reacted to our service.