Rapid prototyping UI/UX pattern and component library

This is a request to develop a flexible, rapid prototyping library that can be used for live prototyping workshops, hackathon planning and general application design on NEAR. We all know NEAR provides the tech to deliver the best UX to web 2 users but need to surface that with great products using great design.

It should be a library of mobile components and flows which accomplish the following:

  1. Gather a bunch of repeatable UI and UX screens, buttons, widgets, logos, etc that are easy to drag and drop into new flows. Assume mobile-first.

  2. Group collections of these into standard flows like onboarding users from instagram, taking credit card payments, selling NFTs, minting NFTs, voting in a DAO, etc etc) so it’s easy to see best practices as well as what’s possible.

Once this has been created, it should:

  1. Have a canonical, editable version for permissioned users but be forkable/copyable by anyone who wants to use it.

  2. Have a microsite dedicated to it once it’s sufficiently hardened up so we can link back to it in an evergreen way and guide new users to using it. We will link to it constantly and launch it on various aggregation sites as a smooth path into blockchain for web2 designers.

  3. Be turned into a development library that allows these components to get easily dropped into applications, a la Twitter Bootstrap or Foundation.

How can we make this happen? v1.0 should be hacky and incomplete and that’s ok – shipping and iterating is more important than perfection by a mile.

Existing work and inspirations:

7 Likes

For these use cases low fidelity is a feature. Keeping visual design opinions out of the library will let app designers imagine their own brand into it. Also prevents people from getting hung up on details when the need is to sketch out a big picture.

This is juicy! I see a lot of value in a library of screens and examples of how they’ve been strung together. “Selling NFTs” screen examples:

Browsing → Item Detail → Wallet → Confirmation

The more of these flows are broken down the more screens/states the library has to pull from. Variations will pop up for screen like browsing (is it a grid? full width? card swipe?). Group those together and when grabbing a Browse Screen there can be productive conversation about which approach is right. When another conversation happens it’s easy to swap it out for a different Browse Screen.

:100:

Each app will have its own look and feel so we don’t need to prescribe visual components. Dev efficiency is already there from reaching for a component library.

From a visual/branding perspective I would like to see guidance on how “powered by NEAR” shows up on the page/app of a partner.

2 Likes

In general, I’m all for this and have myself been formulating a plan to kick off a similar project (I’ve already begun speaking with developers as preliminary research).

I had the pleasure of working on research and design for https://rimble.consensys.design/ during my time in the Ethereum ecosystem, and this sounds almost exactly like what we were aiming for on that project: empowering developers to begin Ðapp development on sure footing by providing a resource full of Ðapp UX best-practices that was well researched and well documented. This is absolutely worth the effort and NEAR is at the stage in its lifecycle where emerging projects could REALLY benefit from a resource like this.

That being said, there seems to be an emphasis here not only on a long-term resource for UX best practices and battle-tested patterns and interactions (all of which take time and research) but also on rapid-prototyping in specific contexts such as workshops and/or ideation sessions that come with unique constraints.

The remainder of my response is influenced by my understanding of the nature of some of our upcoming engagements which have serious constraints and do not resemble the typical day-long or multi-day format of hackathons or similar events.

I think there is a distinction to be made between super short-lived workshops centered on ideation, and more extended efforts like multi-day hackathons as well as general application design. My intent in highlighting this is to exercise a word of caution:

Component libraries are great, but care should be taken for when they get introduced into the design process.

It’s common for folks to jump into doing UI design prematurely. A component library, no matter the level of fidelity, still exists firmly in the realm of the interface. Depending on the context, this often leads to getting too granular too fast, when the focus should really be on ideating at a level of fidelity that precedes interface design. This is so that focus can be directed towards the core problems at hand, rather than how a set of rectangles is to be arranged.

Let’s envision the product design process like so:

  1. Identify an Opportunity
  2. Define the Problem
  3. Define User Needs
  4. Define Critical Paths / User Journeys
  5. Idea / Solution Generation
  6. Prototyping
  7. Testing & Validation
  8. Production & Implementation

If there are ever extreme constraints present in the context of something like a workshop (time or otherwise), or if people are working at a very early stage in the design process where a problem and set of opportunities have not yet been well-defined, I think it’s far more impactful to stick to “paper-prototyping” and an emphasis on defining the problem at hand and a set of core user-journeys/actions/needs.

Then, once sufficient exploration has been conducted around producing a large quantity and variety of potential solutions during an ideation phase, folks can hone in on what they think is the correct path to travel initially. At this point, leveraging something like a component/pattern library makes sense since the focus will have shifted towards creating something more tangible and holistic. It’s not until this point that a designer can truly discern which patterns are actually relevant to their application, and how best to leverage them.

In these cases, I think working towards something like this is well worth the effort. With this in mind, do we feel like this is something we need ASAP? My impression is that there is some urgency surrounding this request. Do we feel like a pattern/component library fulfills our most urgent needs?

3 Likes

With this in mind, do we feel like this is something we need ASAP? My impression is that there is some urgency surrounding this request. Do we feel like a pattern/component library fulfills our most urgent needs?

The most urgent pieces are:

  1. A basic organization of generic screens for standard flow segments, eg onboarding from instagram, paying for something with a credit card, bidding in an auction, … so we can very easily say “don’t worry, this is a 3-step process that looks like web2, see…”
  2. Enough flexibility in those generic screens to be able to copy/paste/modify on the fly to show off bespoke flows too in a very basic way, live.
  1. Identify an Opportunity
  2. Define the Problem
  3. Define User Needs
  4. Define Critical Paths / User Journeys
  5. Idea / Solution Generation
  6. Prototyping
  7. Testing & Validation
  8. Production & Implementation

In our case, there are so many unknown unknowns by the people who are working in steps 1-5 (especially #4-5), that to win step 5 (idea/solution generation), we have to create a back-and-forth loop with step 6 (prototyping). Meaning, people need to see something concrete to ask questions about. We’re definitely still in the “what user ‘problems’ can we even solve?” stage.

It’s like the early days of mobile when it wasn’t even clear what was actually possible… what is a checkout flow in mobile? how do you put in a credit card? What happens when you redirect to a web link? Do mobile apps or browsers save login info?

Thus the library of screens seems very important to anchor the conversation in the Real Stuff We Can Do Today.

Fidelity

The fidelity of the screens doesn’t need to be good at all, tbh, so I agree that they can be purely schematic / flow prototypes rather than UI elements in the early stages. More of a “phone with squares to represent items then a CTA button that has an arrow leading to the next screen” type of thing to start with, though if these are medium-fidelity I’ve found they are more useful than purely box-and-arrows diagrams for anchoring people properly in what’s actually real.

The ASAP goal would be mid-fidelity (boxes, buttons, simple text, arrows, callout bubbles for explanation) drag-and-drop and modifiable visual components which can be stitched together into verbal stories about how a user might flow through the technology to achieve their objectives

3 Likes

A basic organization of generic screens for standard flow segments, eg onboarding from instagram, paying for something with a credit card, bidding in an auction, … so we can very easily say “don’t worry, this is a 3-step process that looks like web2, see…”

Great. I think emphasizing that the primary need initially is for a visual aid to articulate and demonstrate the most high-utility patterns present/possible in NEAR apps is helpful. Due to the initial framing with reference to live prototyping and the inclusion of elements like buttons/logos I think it may have been easy for myself and others to get distracted or to misinterpret.

A focus on NEAR-specific Patterns vs a super versatile and generalized component library is definitely a worthy distinction to make initially to avoid the danger of going too big too fast.

In our case, there are so many unknown unknowns by the people who are working in steps 1-5 (especially #4-5), that to win step 5 (idea/solution generation), we have to create a back-and-forth loop with step 6 (prototyping). Meaning, people need to see something concrete to ask questions about. We’re definitely still in the “what user ‘problems’ can we even solve?” stage.

Again, this is a great articulation of the specific needs. TLDR: “Show me what’s possible so I can riff on it and tailor it to my needs instead of feeling totally lost”. Something that allows for a quick transition between demonstration/education and ideation based on an enhanced understanding.

I definitely think there is still some care that needs to be taken as to when this gets introduced into the conversation during something like a workshop (ie following problem definition), but still a worthy effort and a useful tool for the toolkit.

2 Likes

First/Next step is straightforward I think:

I’ve created a database to begin taking inventory and prioritizing the patterns and components that we want to include as a part of the library: Sign up - Airtable

Anyone can contribute to it, and I’ve included a couple of examples just as a starting point.

A couple of important notes about the scope of this effort:

  1. This is a sizable research project if we want to be able to leverage it with any confidence that it does in fact represent the current state or believable future state of various patterns.

  2. It would be easy to get pulled into designing for “what could be” instead of “what is”. We should explicitly state how much of the design work should be optimistic design and/or how much of it should replicate and demonstrate what patterns currently exist.

3 Likes

Hey, so nice to see this being brought up.

I just bootstrapped something similar here for my own project:
https://master--60d9b2ac2cf86a00396f9b0f.chromatic.com

Just a few elements and components but hopefully by end of summer it will be ample.

Also, in the context of NFTs, it would be great to have components like NFTE.
The quicker you allow creators to put things together with a decent UI the better.

Looking forward to seeing this evolve!

2 Likes

Is there a Miro we can use by tomorrow with these components?