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:
- Identify an Opportunity
- Define the Problem
- Define User Needs
- Define Critical Paths / User Journeys
- Idea / Solution Generation
- Prototyping
- Testing & Validation
- 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?
