Skip to content

Origami Survey Results, Building Components

Posted on by Rowan Manning.

TL;DR:Some charts outlining the results of our recent survey titled "Origami Survey: Building Components"

We recently sent out an internal survey titled “Origami Survey: Building Components”. The survey was designed to gather some quantititive data from our users, and the aim was to help us understand the barriers that teams have to developing their own Origami (or Origami-compatible) components. We sent the survey to engineers, and indicated that we were interested in responses from engineers of all seniorities and levels of experience with Origami.

After two weeks, we had 27 responses from different groups within Product and Technology. This post will explore some of the results, and what we can learn from them. (Bear in mind that while great that we’ve got this many responses, we should be wary of drawing too many conclusions from 27 out of all the engineers in Product and Technology).

To help segment the data, we asked each respondent which area of Product and Technology they worked in, as well as asking them to self-report their level of familiarity with using Origami components.

We’d like to say a big thanks to everyone who filled out the survey 🙂

Familiarity

We asked the question “How familiar are you with using Origami components?”, and asked respondents to mark themselves 1 (What are origami components?) to 5 (I’m an expert). Most people responded with 3 or 4:

How familiar are you with using Origami components? (All Areas)

Area12345
CRM10000
Customer Products00321
Enterprise Services and Security11200
FT Core10100
FT Group Products01000
Internal Products03150
Operations and Reliability01011
Product00100

When you filter this by the area that the person works in, you can see that the groups who have been using Origami for the longest (Customer Products, Internal Products) generally self-report as having more experience.

Creating Components

We asked the question “Did you know that any engineer can create an Origami component?”, and asked respondents to answer yes or no. There ended up being a roughly 50/50 split:

Did you know that any engineer can create an Origami component? (All Areas)

ResponseRespondents
Yes13
No14

When you filter this by the area that the person works in, you can see that Customer Products leans more towards “Yes” as an answer. This aligns with some of our assumptions, as Customer Products have some of their own shared components.

CRM
ResponseRespondents
Yes0
No1
Customer Products
ResponseRespondents
Yes5
No1
Enterprise Services and Security
ResponseRespondents
Yes2
No2
FT Core
ResponseRespondents
Yes1
No1
FT Group Products
ResponseRespondents
Yes0
No1
Internal Products
ResponseRespondents
Yes3
No6
Operations and Reliability
ResponseRespondents
Yes2
No1
Product
ResponseRespondents
Yes0
No1

Prior Experience

We also asked “Have you ever built or contributed to an Origami component?”, and gave respondents the ability to indicate whether they’ve either built a component, contributed to a component, or both. The vast majority of respondents have neither built nor contributed to the development of a component:

Have you ever built or contributed to an Origami component?
ResponseRespondents
Built a component2
Contributed to a component3
Both3
Neither19

What if an Origami component doesn’t exist?

To get an idea of how people are building their front ends, we asked “If there isn’t an Origami component that suits your needs, how do you build that part of your website?”, and gave respondents the ability to select multiple options from the following, or provide their own response:

  • We build and use our own Origami components (Own Origami)
  • We build and use our own reusable non-Origami components, which are used across multiple applications (Own Non-Origami)
  • We build it directly into our application codebase (Directly Into App)
  • We never need anything other than Origami components (Only Origami)
  • We use third-party libraries and components (Third-Party)

Ignoring responses of “Other” for now, the results look like this. You can see that in the majority of cases, if an Origami component is not available then front-end code gets built directly into people’s application codebase:

If there isn’t an Origami component that suits your needs, how do you build that part of your website?

Area

We build and use our own Origami components

We build and use our own reusable non-Origami components, which are used across multiple applications

We build it directly into our application codebase

We never need anything other than Origami components

We use third-party libraries and components

CRM01101
Customer Products22411
Enterprise Services and Security00203
FT Core00000
FT Group Products00000
Internal Products03704
Operations and Reliability00301
Product00100

The “Other” responses to this question are as follows:

  • We beg origami to consider it for their roadmap 🙏, rally others who may benefit from it too
  • Didn’t hit such case. Even if I did, would use some simple custom elements. Instead of including other third party libs
  • We copy/paste it from another repo that’s done something similar
  • Sorry, I’m just not familiar with Origami components
  • I’m new :D Never had to touch an Origami component yet!
  • Talked to Origami developers who then worked with us improving existing components to meet our requirements

We can see that very few people build Origami-compatible components outside of the Origami team. Engineers are also more likely to use third-party code than build their own reusable components.

Other Feedback

We also got a lot of useful responses in free-text fields at the end of the survey. We’ll be reading and understanding these over the next few weeks. We’ll keep you posted on any work that we decide to do based on the results of this survey.

Thanks again!
The Origami team