A summary of design & development activity and KPIs for the OpCo product team in September 2023.
Team updates
Tim Robinson, one of our full-time developers, left Balancer OpCo on the 22nd of September. Tim was primarily responsible for our initial pools/SOR API implementation but contributed to numerous features in the frontend app over the 2 years he worked in our team. I’d like to take this opportunity to publicly thank @timjrobinson for all his hard work. The app would not be where it is today without his input.
Development
In September, our focus has been primarily on feature improvements. In particular, we focussed on improvements around LP portfolio management and veBAL management. Below is a high-level list of the more significant work completed.
- Portfolio page UI/UX improvements (#3700)
- veBAL management UI/UX improvements (#4028)
- Multi-pool voting (#4196)
- Enable veBAL sync on Base and Avalanche (#4223)
- Filter veBAL table via URL params (#4239)
In addition, some significant ongoing work that was started by Tim in August is to update the frontend to work with the new Beets/Balancer pools API. This is a big project and will require further work in October.
The content above covers the work completed in September at a high level. For a more detailed breakdown of most of our work, you can browse the frontend repo releases page 1 - 2.
Design
Below is a high-level list of design activities in August.
- UX/UI design around improvements to core pool actions, like Joins, Exits, Stake and Unstake.
- UX/UI design around improving the pool search experience, including designs of how an inline token search (instead of modal token search) could work.
- UX design around a card-based system for displaying pools, as an alternate view to the regular table-based layouts.
- UI feedback and frontend dev tweaks to support the launch of the new veBAL improvements.
- UI feedback and support around the implementation of the new veBAL multi-voting feature.
DNS Security Incident
Some work was also required to respond and recover from the DNS security incident on the 20th of September, described in detail in this blog post.
KPIs
Transaction flow error-free rate (30d): 93.7%
= 1 - (‘fatal’ errors / total successful txs)
Where ‘fatal’ is a label applied to errors recorded in a transaction flow, and total successful txs are recorded via analytics events.
Note:
- Ad blockers prevent error recording and analytics.
- Some % errors are user/wallet-controlled errors that we haven’t excluded yet.
- Total fatal errors: ~4,404 (prev. 18,388)
- Total successful txs: ~70,000 (prev. 118,500)
This KPI has drastically improved since last reported at 84.4%. The reason it was so low in August is explained thoroughly in our August update. In summary, we did the work to improve this KPI in July/August but it was distorted by issues with the zkEVM chain and the vulnerability recovery withdrawals. We will continue to monitor and fix failed transaction issues to get this KPI as close to 100% as possible.
Lighthouse benchmark
Note, as mentioned previously, it’s not possible for us to make significant improvements on performance without a change in stack, e.g. some server rendering with Next or Nuxt.
Not much has changed in the reported metrics compared with August. Again, Lighthouse scores can be relatively unreliable. However, for our purposes, they serve as useful benchmarks by highlighting any significant issues or improvements that may have been introduced.
User satisfaction score: TBD
Avg. time on site (30d): 1:50 (-0:31s on previous 30d)
Note, that the Average Time on Site metric can be influenced by market conditions. For instance, we observe an increase in time spent on the site when the market is on the rise.
We have started conducting user interviews to gain a better understanding of what our core users are using the app for and what they’d like to see improved. This is the first step towards implementing a more robust user satisfaction system.
In October we will look to integrate a system for collecting user feedback within the UI.