Build a design system and rapidly iterate to bring a minimum viable product DApp to market on Ethereum Mainnet.
Establishing an MVP
The client handed us a partially built project, so establishing the core features was a key starting place. Leading the discovery, I helped to build consensus amongst the entire team by creating a flow diagram that mapped the most important features of the application.
That document allowed us to create a feature list and do the collaborative exercise of connecting those features with the different parts of the application to be sure we had captured all of the necessary features in our backlog.
From there our team could establish a data structure for the core elements of the DApp — and thus work simultaneously on building out the API, chain integrations, and user interface.
Building a Design System
My focus was on establishing the design system that would allow us to rapidly standup the key features of the application and having a working prototype as soon as possible. A design system always begins with global variables and mixin/function utilities. Once those are established, I start building out core components that test out the global variables and help me to make adjustments as the system starts to take shape.
Why a Design System?
Taking the time to build this way is actually slightly slower at the beginning than just throwing together a nice looking layout and building it from scratch, but the value shows through as an application begins to scale. Once core components — text, button, link, layout containers, icons, and form inputs, etc — are built, it becomes possible to start new features with a simple wireframe and produce a functional prototype — no high fidelity mockups required.
Component Driven Development
The pattern of component driven user interfaces partners well with test driven development practices as well as documentation add-ons like Storybook. Essentially, a little bit of extra effort up front improves both the developer and user experiences with the application. An intrinsic part of my skill-set is building out components and tooling that empower other developers who may not have my design sensibilities to build out new interface features with existing components while maintaining consistent interface patterns that lend themselves to excellent user experience.
What I Learned
Next.js and how to migrate a late stage React app to Next.js
Shortly before launch, it was discovered that this DApp needed server side rendering capabilities for a particular feature which the client considered essential — a major problem as the beta DApp was deployed on Vercel. After exploring all other options, we decided to migrate from CRA to Next.js in order to maintain the rest of our stack and use Next.js' built in SSR functionality.
As the person with the most technical experience on the team, I did the primary migration. I was also brand new to Next.js, so I was learning Next.js while figuring out which of the features built in React would need to be modified to play well with Next.js' modified application structure. Overall the process went smoothly. It took longer than anticipated, but was ultimately successful and allowed us to launch the full product only a few weeks later than originally planned.
I learned a ton about Next.js and have built several things using it since — including this site!