Improving the developer experience
Increasing productivity by adding JavaScript testing
About Budibase
Budibase is a low code app builder that helps developers save time building internal tools.
The target audience are developers and IT professionals who are comfortable using databases but don't build frontend interfaces.
My role
As the only designer at Budibase, I take full ownership of the design process:
Research
Idea discovery
User journey maps
Wireframing and UI Design
Prototyping
User testing
Throughout the entire design process, I always collaborating with our engineering leads to make sure that my designs are feasible and attainable within the set timeframe.
Intro
Whether you're an experienced developer writing custom JavaScript or a low code novice at some point you will want to use data inside your app.
Using JavaScript and bindings allows you to take values from your tables or queries and use it in your app.
Hello Andrew
Problem
There is no easy way to test your JavaScript and our users get frustrated trying to debug their code.
This was leading to more customer support requests and discord discussions with people looking for help.
Research
I started off by speaking to our customer support team and some users who had reported problems to gather some insights.
"We have a lot of tickets surrounding using JavaScript and bindings"
"We find it really hard to debug a customers application, all the code needs checked outside Budibase to see if it's a problem with the code or the binding"
"I never code in Budibase, I use CodePen and JS fiddle"
Initial "Run test" idea
This idea was to allow the user to click "Run test" on their JavaScript, this would then present the user with UI to fill out values for their bindings before running the JS.
This was following an existing pattern we use to test automations to keep the UX consistent across the builder.
Internal feedback
After sharing the idea with some of my team here where some of the key points raised:
"This would solve the problem but would I have to fill out these values every time?"
"We would rather fill out the details in the drawer rather than a modal"
"I would just replace the bindings with values in the JavaScript code if I wanted to test it"
Live evaluation on bindings
After sharing the idea with one of our lead engineers, they suggested adding live evaluation for bindings, this would mean the user could get values for bindings like $("Current User.firstname") automatically.
This simplified the experience and allowed me to remove the step of filling out values. Big win!
Iterating on the design
After getting a POC that we can get values automatically, I updated the design to incorporate some of the feedback.
Removed the step to fill out values
Created a new space in the drawer to display the outputs
User testing
I jumped on a call with some of our users to test out the prototype and get some feedback
"Can't it update in real time instead of clicking run?"
"Quite often I will return more than 1 line"
"Expanding the results every time will be annoying"
"I don't like scrolling up and down to see the output"
Final designs
Adjustments
Added tabs to switch between bindings, preview and snippets (Snippets was also in design during this project)
JavaScript gets evaluated automatically, so the user doesn't need to click run.
Update the label to "Preview" based on feedback
Added an option to copy the output based on feedback
Additional improvements
Added the field name to the top of the drawer to give the user more context on what they are adding code to
Added expand option to give the user more space
Improved usability on drawer stacking
