Just3things (formerly Cadence) was built in-house at OVO Energy to help retain the transparency of being a start-up, focus the company on achieving long term goals, and improve alignment across the business. Initially envisioned as a goal setting and achievement solution with a particular focus on OKRs, as we began gaining external customers we changed strategy to help cross functional teams maintain alignment at scale.
Priorities & Goal Setting
Following extensive customer discovery interviews and heuristic analysis, we first decided to improve the goal setting flow, and second to introduce a feature to allow people to indicate their top three priorities, with the idea people should focus on at most 3 things at one time - hence the name change. Both projects exposed deeper issues with the product that we needed to tackle.
For the goal setting piece, our experiments led us to discovering that people engaged in a very different way with goal setting than we had previously thought. This required a redesign of how we talked about goals and targets to our users, and a rebuild of goals in the backend.
Priority setting had been a feature requested by a major stakeholder, and the mechanism we had created for this was not heavily utilised by our users. Through further interviews and behaviour analysis we realised that priorities would make a lot more sense in a team context.
Further to our discoveries with priorities and goal setting, and our understanding of OKRs working best in a team context, we used customer experience mapping, a design sprint, and commercial strategy reviews to target cross-functional teams. The problem area we were investigating was teams’ internal alignment to long term goals, and their external alignment to overall company objectives.
To solve for this we developed an MVP of a team area with shared goals and priorities, a module for regular stakeholder updates and documents, and a comments and activity feed related to ongoing work.
Jobs to be Done
Towards the end of my time at Just3things, we used Jobs to Be Done as a way to gain a better understanding of why our customers were using the product, what need it was fulfilling. We initially found this technique quite useful, as it really surfaced what value we were delivering to our users and the buyers of the product.
However, on reflection, I consider this to be a reaction to how we had been writing User Stories for our agile development process. While it was initially useful when talking to senior stakeholders, it created an extra layer of abstraction which was unhelpful for the team.
Pattern Library & Style Guide
In collaboration with the engineering team, I spearheaded the creation of a style guide and pattern library in order to speed up front end development for the app. We carried out a UI audit, from typography and form elements to animations and modals, agreed on categories and naming conventions, which later informed how we discussed all future interface updates. This process helped us speak the same language as a team.
As a result both designers on the team started regularly pushing front end code to production and had more of a say in how the UI was constructed, something we both had strong opinions on. On the developer side of things, they now felt more confident discussing design issues and were involved more from the beginning of discovery, so our process was a lot less waterfall. This helped with team cohesion and our velocity and flexibility.