A summary of design & development activity and KPIs for the OpCo product team in February 2024.
Development
Our focus in February has been on progressing the development of the v3 app so that a beta release is possible in April. That is, to have:
- A network-agnostic pool explorer.
- A pool detail page.
- Core pool actions (add/remove/stake/unstake) for standard (weighted/stable/composable stable) v2 pools.
- A swap UI for v2 swaps.
- A portfolio page with per pool and per network claim all actions.
The core functionality of this work has been done. We are now working through edge cases and UI/UX design implementation. Note that this target does not include support for testnet v3 pools in the beta release, however, because of the frontend/API/SDK architecture v3 support should be trivial and will be worked on alongside our current work.
Design
Below is a high-level list of design activities in February.
- UX/UI design for the V3 web app:
- A new âstepsâ module for actions (e.g. within add liquidity) to keep users informed about their progress during multi-step transactions.
- Finalizing the Stake & Unstake flow
- Refined yield tooltip, including points
- Add liquidity refinements for special pools that require liquidity to be
- Adding guard rails around high price impacts to prevent users from getting rekt.
- Simple portfolio page and liquidity incentives claims experience
- UI/UX design for the V2 app:
- Partner protocol pointsâdesigning options for points for partners like Ether.fi and Swell could be promoted within the app.
- V3 marketing
- Developing graphical styles for marketing collateral and social posts.
KPIs
= 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 we havenât excluded yet.
- Total fatal errors: ~4,644 (prev. 5,534)
- Total successful txs: ~81,498 (prev. 86,703)
This KPI has improved slightly since last reported in January at 93.6%. We have not done any work to fix issues in v2 in February so this can only be attributed to changed network or user conditions. We will continue to monitor and fix failed transaction issues to get this KPI as close to 100% as possible.
Note that our primary focus is on the v3 app development. When critical errors come up that can be fixed we will do this ASAP. The errors we are seeing that prevent us from reaching 100% error-free rate are often non-trivial to replicate and fix.
Avg. time on site (30d): 2:01 (+0.06s)
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.
Taken from this article about what makes a good NPS score: âIf your NPS is higher than 30, that would indicate that your company is doing great and has far more happy customers than unhappy ones.â.
As can be seen in the general trend chart above, the NPS score has remained fairly constant at around the 50-60 level. We actually see a negative pressure on the score as gas prices increase. Users start to complain about the prices and give lower ratings. Despite this, our score has been increasing since December which is a positive sign that the app is performing well.
Lighthouse KPI
We had previously been reporting the Lighthouse performance score here as a way to track general app performance health over time. However, since we are no longer doing much work on the v2 app it rarely changes. Itâs also quite an unreliable metric and so for now we will stop reporting it as a KPI. With the launch of v3 we will start to report a different performance-related metric provided by Vercel, where we host our frontend apps.