In the wake of ETHGlobal’s Metabolism hackathon, 0xTranqui published a repository and app that together exists as a scaffold for developers building on top of the Zora protocol. The site features handy components that allow users to interact with Zora’s marketplace contracts. In addition, it provides a glimpse into the capabilities of Zora’s indexer, as well as fine tune controls surrounding Zora’s latest Drops and Editions contracts.

I set out to redesign this site.

I began by creating a handful of interaction diagrams to provide a high level sense of the current user experience. This process provides a way to highlight potential areas of focus when considering improvements to user flow. Because the existing create page and API page have linear flows that don’t include much nuance, I instead focused on the protocol page, as it contained the most complex interactions.

I created state diagrams to get a better sense of these individual interactions, beginning with token approvals.

Fig 1: After connecting your wallet, the site will determine the state of approvals among one of three modules, as well as that of the transfer helper. Shown above is the potential variety of these states, in the context of the asks module.

I continued to create a flow diagram that outlined the process of calling a write function. Embedded in this diagram is a separate approval flow (not included) that relies on the state diagram provided above.

How can users be made more aware of the application state necessary to submit transactions? How can redundancy in the interface be minimized, while continuing to provide users an adequate amount of context?

These questions guided the beginning of the screen design process. Focus remained on the protocol page, foreseeing that that design process would include the most complexity.

Fig 3: This wireframe includes all the building blocks needed to replicate the site’s existing functionality. The main design decision made was to separate each module into individual pages. This would drastically reduce clutter while allowing users the ability to conceptualize each module independently. Token approvals would continue to appear below the image preview, but in contrast to the original site, the token id would remain consistent when navigating through the three modules. The interaction that enabled this navigation was a separate design decision.

Fig 4: While deciding between a dropdown menu and tabs for the aforementioned interaction, I came across this helpful article on segmented control. The author articulates that if a user’s selection filters or changes page content, tabs are appropriate. That being said, I was able to rule out a dropdown component for this particular instance.

From here focus shifted towards the contract interaction section, which included the inputs for each token, contract address and id, respectively.

Fig 5: Designing a component that felt balanced was difficult considering the utterly opposite lengths of the inputs. I played around with shortening the contract address input similar to how it appeared in the original implementation. Initially, I concluded that the presence of a shortened address prefixed by an ellipsis would be sufficient. But later, I shifted priority to the beginning characters of an address postfixed by an ellipsis, as it’s a more standardized approach and more likely to match wherever the user copied the address from in the first place.

In regards to how the actual functions would appear with their expected arguments, I visited Etherscan for inspiration, assuming that its interface would be most familiar to developers experienced in contract interaction.

Fig 6: Above is the first iteration of the module manager taken to high fidelity. In the contract interaction section, function arguments don’t appear in the default state and instead (as shown below) they appear when the disclosure is opened.

Fig 7: By using a progressive disclosure for this interaction, users are less likely to be overwhelmed by a crowded page.

I compiled a rudimentary design system consisting of color and typography standards that was pieced together through a thorough investigation of Zora’s documentation website, creator toolkit, and zora.co. This system was used to generate the early mocks, before discovering Zord.

What is Zord?

Zord is a UI library from the Zora team built on top of Vanilla Extract. It’s existence enabled me to reverse engineer my designs and create further consistency with Zora’s branding and components. By taking the initial mocks created in Figma, and implementing them using Zord, I created a local design system that mirrored an internal UI kit.

Given that a UI library was now part of the workflow, I restructured the existing mocks using Zord components. I also introduced a playful accent color as a nod to 0xTranqui who had used it in the original design.

Fig 10: With some exceptions, I made an effort to lean into the design constraints provided by Zord instead of overriding styles. This was because I was redesigning a Zora product and I wanted it to feel that way out of the box.

The redesigned landing includes a CTA that brings you into the module manager, as well as a button that allows developers to easily populate their clipboard with the prompt necessary to clone the repository. Additionally, I renamed and reordered the pages in the header in order to provide more context for unfamiliar users.

Designing the module manager page provided a layout framework that could easily be applied to the create page. The gist is two static sidebars with a column in-between capable of handling content overflow.

Fig 12. When clicking on the various input fields, a small window appears that provides guidance to how the respective input should appear. This is necessary because the existing interface provides more granular control over the contract arguments.

During my experience designing and developing the minting site for Magenta Hydrangeas, I discovered that certain fields exist in this interface that are abstracted away on create.zora.co.

I’m still in the midst of redesigning the API page. At the moment, my attention has been pulled towards work on recent editions. However I’m still interested in continuing with this project and would be eager to see these designs through to implementation.

If you have any questions or feedback, please feel free to send me a message on Twitter. Lastly, thanks very much to 0xTranqui for creating this app in the first place, and to the handful of friends who read over and helped edit this article.

In the wake of ETHGlobal’s Metabolism hackathon, 0xTranqui published a repository and app that together exists as a scaffold for developers building on top of the Zora protocol. The site features handy components that allow users to interact with Zora’s marketplace contracts. In addition, it provides a glimpse into the capabilities of Zora’s indexer, as well as fine tune controls surrounding Zora’s latest Drops and Editions contracts.

I set out to redesign this site.

I began by creating a handful of interaction diagrams to provide a high level sense of the current user experience. This process provides a way to highlight potential areas of focus when considering improvements to user flow. Because the existing create page and API page have linear flows that don’t include much nuance, I instead focused on the protocol page, as it contained the most complex interactions.

I created state diagrams to get a better sense of these individual interactions, beginning with token approvals.

Fig 1: After connecting your wallet, the site will determine the state of approvals among one of three modules, as well as that of the transfer helper. Shown above is the potential variety of these states, in the context of the asks module.

I continued to create a flow diagram that outlined the process of calling a write function. Embedded in this diagram is a separate approval flow (not included) that relies on the state diagram provided above.

How can users be made more aware of the application state necessary to submit transactions? How can redundancy in the interface be minimized, while continuing to provide users an adequate amount of context?

These questions guided the beginning of the screen design process. Focus remained on the protocol page, foreseeing that that design process would include the most complexity.

Fig 3: This wireframe includes all the building blocks needed to replicate the site’s existing functionality. The main design decision made was to separate each module into individual pages. This would drastically reduce clutter while allowing users the ability to conceptualize each module independently. Token approvals would continue to appear below the image preview, but in contrast to the original site, the token id would remain consistent when navigating through the three modules. The interaction that enabled this navigation was a separate design decision.

Fig 4: While deciding between a dropdown menu and tabs for the aforementioned interaction, I came across this helpful article on segmented control. The author articulates that if a user’s selection filters or changes page content, tabs are appropriate. That being said, I was able to rule out a dropdown component for this particular instance.

From here focus shifted towards the contract interaction section, which included the inputs for each token, contract address and id, respectively.

Fig 5: Designing a component that felt balanced was difficult considering the utterly opposite lengths of the inputs. I played around with shortening the contract address input similar to how it appeared in the original implementation. Initially, I concluded that the presence of a shortened address prefixed by an ellipsis would be sufficient. But later, I shifted priority to the beginning characters of an address postfixed by an ellipsis, as it’s a more standardized approach and more likely to match wherever the user copied the address from in the first place.

In regards to how the actual functions would appear with their expected arguments, I visited Etherscan for inspiration, assuming that its interface would be most familiar to developers experienced in contract interaction.

Fig 6: Above is the first iteration of the module manager taken to high fidelity. In the contract interaction section, function arguments don’t appear in the default state and instead (as shown below) they appear when the disclosure is opened.

Fig 7: By using a progressive disclosure for this interaction, users are less likely to be overwhelmed by a crowded page.

I compiled a rudimentary design system consisting of color and typography standards that was pieced together through a thorough investigation of Zora’s documentation website, creator toolkit, and zora.co. This system was used to generate the early mocks, before discovering Zord.

What is Zord?

Zord is a UI library from the Zora team built on top of Vanilla Extract. It’s existence enabled me to reverse engineer my designs and create further consistency with Zora’s branding and components. By taking the initial mocks created in Figma, and implementing them using Zord, I created a local design system that mirrored an internal UI kit.

Given that a UI library was now part of the workflow, I restructured the existing mocks using Zord components. I also introduced a playful accent color as a nod to 0xTranqui who had used it in the original design.

Fig 10: With some exceptions, I made an effort to lean into the design constraints provided by Zord instead of overriding styles. This was because I was redesigning a Zora product and I wanted it to feel that way out of the box.

The redesigned landing includes a CTA that brings you into the module manager, as well as a button that allows developers to easily populate their clipboard with the prompt necessary to clone the repository. Additionally, I renamed and reordered the pages in the header in order to provide more context for unfamiliar users.

Designing the module manager page provided a layout framework that could easily be applied to the create page. The gist is two static sidebars with a column in-between capable of handling content overflow.

Fig 12. When clicking on the various input fields, a small window appears that provides guidance to how the respective input should appear. This is necessary because the existing interface provides more granular control over the contract arguments.

During my experience designing and developing the minting site for Magenta Hydrangeas, I discovered that certain fields exist in this interface that are abstracted away on create.zora.co.

I’m still in the midst of redesigning the API page. At the moment, my attention has been pulled towards work on recent editions. However I’m still interested in continuing with this project and would be eager to see these designs through to implementation.

If you have any questions or feedback, please feel free to send me a message on Twitter. Lastly, thanks very much to 0xTranqui for creating this app in the first place, and to the handful of friends who read over and helped edit this article.