Origami Survey Results, Building Components#

Posted on 20 April 2020 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)
Area	1	2	3	4	5
CRM	1	0	0	0	0
Customer Products	0	0	3	2	1
Enterprise Services and Security	1	1	2	0	0
FT Core	1	0	1	0	0
FT Group Products	0	1	0	0	0
Internal Products	0	3	1	5	0
Operations and Reliability	0	1	0	1	1
Product	0	0	1	0	0

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)
Response	Respondents
Yes	13
No	14

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
Response	Respondents
Yes	0
No	1

Customer Products
Response	Respondents
Yes	5
No	1

Enterprise Services and Security
Response	Respondents
Yes	2
No	2

FT Core
Response	Respondents
Yes	1
No	1

FT Group Products
Response	Respondents
Yes	0
No	1

Internal Products
Response	Respondents
Yes	3
No	6

Operations and Reliability
Response	Respondents
Yes	2
No	1

Product
Response	Respondents
Yes	0
No	1

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?
Response	Respondents
Built a component	2
Contributed to a component	3
Both	3
Neither	19

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
CRM	0	1	1	0	1
Customer Products	2	2	4	1	1
Enterprise Services and Security	0	0	2	0	3
FT Core	0	0	0	0	0
FT Group Products	0	0	0	0	0
Internal Products	0	3	7	0	4
Operations and Reliability	0	0	3	0	1
Product	0	0	1	0	0

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