Working with Non-Developers on Front-End Projects

Quicker feedbacks and clearer communication between developers and non-developers, working on a front-end project.

Working with non-developers as if they are part of the dev team

As developers, we do our best to collaborate as efficiently as possible. We make sure our code is clear using a standardized code style and recommended design patterns. We automate everything in our workflow, making sure communication (either code or natural language) is fast and precise. We release new code updates as often as possible with a CI/CD setup, testing and catching errors as soon as possible.

It’s all great but front-end development is not exclusive to front-end developers — good collaboration should include non-developer as well.

So, why do we settle for inefficient communication between developers and UI designers/ UX designers/ PMs and, in some cases, the clients?

In this post, I suggest a solution to the ‘inefficient-collaboration problem’ using Bit.dev and a couple of integrations.

The solution (an example workflow)

1. Lisa, a front-end developer, builds/updates a component in her current project.
2. Lisa publishes her new/updated component to Bit.dev
3. An automated notification containing Lisa’s username and the component’s details is sent to all stakeholders via Slack. Anyone with an interest in that component (as a co-maintainer, a consumer, etc.) is welcomed to review it in Bit.dev’s playground.
4. Designers/product managers are automatically assigned a task in the company’s task manager of choice (e.g, Asana), asking them to review the new/updated components in Bit’s playground and validate that it indeed follows specifications.

Delivering and reviewing independent components

Bit.dev is a cloud component hub. It is a place to publish, document, organize and collaborate on individual front-end components (React, Vue, Angular, Svelte, etc.).

Published components can be reviewed in Bit’s playground, installed using NPM/Yarn or cloned into any repository, using Bit’s CLI.

Cloned components can be modified in their “host repository” and published back (as updated versions) to Bit.dev.

So, in a nutshell, Bit.dev is both a tool for building design systems and a way to deliver features and code updates as independent components.

Exploring published React components in Bit.dev

Read more on how to publish components using Bit, here:

Maximizing Code Reuse in React

And, to keep this post short and to-the-point, I won’t go over all the great merits of component-driven design or design systems — if you’re not convinced, I suggest you read these posts on the subject:

How to Gradually Build a Design System

A Guide to Component Driven Development (CDD)

Integrating Bit.dev with Slack and Asana

Communicating Through Components

Delivering changes as components makes it easy to notify your team of changes in a more abstract way. A change to a component is easily understood, it means a certain feature has been changed. This abstract way of communication is what enables all teammates, developers and non-developers alike, give their input as quickly as possible (the sooner a fix is made the less costly it will be).

Bit + Slack

Slack is today’s number one tool for collaboration. It is practically used everywhere. If you want your teammates to know about anything — this is where it has to happen.

To integrate Bit with Slack:

1. You should have a Bit.dev organization (an organization is an entity that groups all component collections)
2. You should have at least one collection (collections are essentially scopes of components, used to organize components, set permissions, etc.). This collection has to be owned by your organization and not by your user.
3. Enter your organization and click on “Integrations” (on the top right corner)
4. Install the Slack integration
5. Configure your notification preferences: on which Slack channel you’d like to be notified and on what events or “actions”.

For example, when a component gets “exported” (published), your team receives a notification that includes the author’s name, the type of action (export), the number of components related to that specific action and the target component collection.

Bit Webhooks + Zapier + Asana

Unlike Bit’s ‘out-of-the-box’ integration with Slack — our integration with Asana will take some effort on our side.

Bit offers webhooks as a way to integrate it with whatever tool you choose. In our case, will use Asana to assign the relevant tasks to the relevant teammates.

But first, just so we’re on the same page — what are Webhooks?

Webhooks are a common way for one app to notify of an event, in real-time, to another app. Webhooks are often referred to as “reverse APIs” because the app consuming the data does not do so by sending an HTTP request to another API — instead, it makes an API available for the app sending the data (usually, a POST HTTP request sending data in a JSON format).

Setting up Bit Webhooks

1. You should have a Bit.dev organization (an organization is an entity that groups all component collections)
2. You should have at least one collection (collections are essentially scopes of components, used to organize components, set permissions, etc.). This collection has to be owned by your organization and not by your user.
3. Enter your organization and click on “Integrations” (on the top right corner).
4. Install the Webhooks integration.
5. Configure your Webhooks preferences.

• Actions: Select on which events you’d like to be notified.
• Collection: Select the location or scope of components, to be notified of.
• Webhook URL: Insert your API endpoint (the receiver of data).
• Secret Token: Insert a value that would serve as a way to authenticate the source of requests made to your API.

A POST request from Bit.dev will have the ‘Secret Token’ in its header, at x-bit-token

The data (JSON) will have relevant component IDs (an array), the collection name (the scope of these components) and the username of the action initiator.

For example:

{
  "action": "export",
  "bitIds": [
    "collaborative-org.shopping-cart-collection/button"
  ],
  "username": "eden"
}

Using Bit’s Webhook to trigger Zapier

Zapier is used as a way to simplify the process. The implementation here is totally up to you, whether it's Zapier or your own solution.

First, I’ll choose ‘Webhooks by Zapier’ as the ‘App’. Then, I’ll set the triggering event to ‘Catch hook’.

I’ll then copy the URL generated by Zapier and paste it as my ‘Webhook URL’ in Bit’s Webhooks configuration page. This will serve as my URL for component exports made to the ‘shopping-cart-collection’.

I’ll then export a component and ask Zapier to verify it catches the request

I’ll then select the step to be initiated as ‘Asana > Create a new task’ and pick my ‘Review UI Components’ project, a project I’ve created just for that.

Here, I’ve mapped the received JSON (from Bit’s webhook) to the corresponding fields.

This will create the following task in Asana:

We have an automatically-created task on Asana, that asks a non-developer to review a new or updated component. Thanks to Bit.dev’s playground, he or she can check out the code example rendered, isolated from any specific project.

A published modal-window component rendered in Bit’s playground

Feedback from the designer/manager can be given through Asana, as well.

Conclusion

Building front-ends with a component-first approach is great for all sorts of well-known reasons but when combined with Bit.dev, it opens the gate to much more productive communication between developers and non-developers.

Learn More

Tools for Consistent JavaScript Code Style

9 Tips for Building Awesome Reusable React Components

Maximizing Code Reuse in React