This article is about how a partner pushed us to open up our SaaS for a lot of configurations and extensions and how we handled it with a little help from the Jobs To Be Done framework. I hope it is useful for teams and individuals that might feel overwhelmed by requirements.
Today we announce a new partnership with ESNAF toys – handmade wooden magnetic toys for kids and adults. ESNAF is using BuildIn3D to visualize 3D assembly instructions for the Nordic Fox available at ESNAF Nordic Fox – https://esnaftoys.com/pages/esnaf-toys-3d-play
Here is the Fox itself and the story of what we as a SaaS learned from a good partner and how to best facilitate the requirements exchange.
The Fox
Nfox_3d_toyThe requirements
We got in touch with ESNAF toys about a year ago. From the start we kind of started flirting with the idea of visualizing the magnetic wooden toys and discussing the large big picture of toys, play, interaction, story, challenges and how the physical and the digital are brought together.
About 2-3 weeks ago we were both ready to take action and the team behind ESNAF toys came with over 26 requirements over the course of the project.
Step 1 – step back and figure out if the requirements make sense on the high level
Brands that use BuildIn3D could easily embed our 3D assembly instructions on their web site. ESNAF came to us with a lot of requirements to make the visualization look and feel similar to the UI, theme, colors of the website. In this way users will have a consistent experience. We grouped all the requirements and thought really hard – “Does this make sense?”.
Step 2 – get the Jobs to be done right and list how you are going to accomplish them
The framework for Jobs to be done was really helpful for us in this case. Here is one of the jobs to be done that we identified for ESNAF:
JTDB-1 – When I as a brand with an ecommerce website bring a user to a web page, help me demonstrate the product in an interactive way, so I can engage the user.
Here is one Job to be done for the user of ESNAF
JTDB-4 – When I as a user visits the website of a brand, help me understand the product they are selling better without my required interaction, so I can make an easier decision if I am interested in the product.
We identified 14 of those for specific cases. We then went one step further.
For every JTDB we listed how we are going to accomplish it, directly below the JTDB. We created a “Get the job done with” to every Job to be done and it started to look like this:
JTDB-1 – When I as a brand with an ecommerce website bring a user to a web page, help me demonstrate the product in a interactive way, so I can engage the user.
Get the job done by using autostart=true param as configuration
Get the job done by using ‘steps’ and ‘waitTime’ params to configure the experience of how long the instruction should play.
This process of identifying a JTDB and listing a “Get the job done” for every JTDB helped us reduce the configuration params that we had with 30%. We understood on a deeper level that we don’t need them to get the job done for the brand. It also helped us identify about 20 more configuration parameters that we had to open as an API.
The Instructions Steps framework that is responsible for visualizing the instructions consists of about 70 extensions and every extension provides a number of configuration options to developers, but they were not whitelisted and made public to users. We kind of always knew there will come a time when we will have to open many of the configuration options to end users, but it felt overwhelming to even consider how to structure more than 200-300 configuration options. From an engineering perspective it is challenging to even structure them, group them, document them and support them. Additionally, once you make a configuration option public it is an API and you support it until the end of the internet.
Step 3 – it’s an artistic expression. Focus on the detail and provide the tool
To create a good experience, ESNAF was focusing on the details. Like the font that is used on the buttons, the size of the BuildIn3D logo in the upper right. It is important for ESNAF to even have a different color on the bounding box that highlights the currently placed element.
We had no data to support that one size is better than the other or that one color of a bounding box is better than another. Then we realized – it is not about Data in this case as it is with other partners that are engineering organizations and need the data.
Here, it is about “artistic expression”. Data could come handy as we already have over +200M events from users following assembly instructions, but probably it is more art than science for toys. We don’t know…
We made a decision to list our job to be done in this case
JTDB-12 – When we as a SaaS, provide a feature to our clients,
help us provide the tools along with the recommended default options,
so clients can make decisions and express themselves artistically.Get the job done with “steps” and ‘waitTime’ to control the speed of autoplaying the instructions without the need to discuss with the client.
Get the job done with “autostart” for clients that want to turn it off/on by default.
In this example we figured out – “Hey, do we know what should be the waitTime when autoplaying an instruction?” The answer is no and even more so – there is no right answer. It depends on the experience that you want to bring and how the brand wants to communicate itself.
We provide the tools and the recommended options, but brands are free to configure everything. With ESNAF we even configured the steps when zooming on the model and how fast you zoom and this is different from other brands and platforms.
Conclusion
Get the requirements. Think really hard does this make sense on a high level. Get the jobs to be done right – as many of them as possible and list a “Get the job done by” for every JTDB. We provide the tools and the recommendations to control things on a really low level, and we leave it up for the brand to play with these configurations and to express themselves.
