When we started setting our project in motion a few months ago, it was clear that the composition of the team —a micro-team by most metrics — was leaning towards a certain set of skills: agreeme is made of a product manager and two cloud software engineers.
Three was our magic number, informed by wanting to plan the software using a lean approach and using intuition from Fred Brooks’s law on software management “adding manpower to a late software project makes it later”. Even for a greenfield project, we did still abide by the idea that there is agility in lower numbers. That meant three people to architect, plan and design all the original aspects of our minimum viable product (MVP).
We’ve got to know early on that regardless of whatever marvel achieved in building infrastructure as code, in product planning and methodology or in performing a difficult software library upgrade, it would be whatever we put in the hands of the users that would finalise their first experience of agreeme.
We live in an era of digital abundance and users have a right to permanently feel commitment anxiety and lingering suspicions when faced with what can appear as ‘one more app’, especially one that asks for personal information. The time to generate a “spark” between a product and its user can be infinitely short. The audience’s expectations for a good user experience (UX) is constantly levelled up by the herculean research and innovations around the behaviour of the user, their motivations and their implementation into gratifying experiences led by the huge players of the tech sector.
We can thank a degree of self-awareness within the team to not only realise the might, but also to the limitation of our combined skills, telling us to take the time to learn and leverage a new discipline: how to engineer good user experiences, and grasp what hides behind this immensely vast and oftentimes ethereal concept.
Taking a step back allowed us to think about how objectives and metrics can be leveraged to help us build more confidence in our decisions.
Committing to mobile
Deciding on which platform we would ship the software on was a major and pivotal step that we agreed early on. Whilst we initially contemplated the idea of building a web app, we eventually settled on an iOS and Android variant.
Aside from the thrill of a challenge (none of us had previous product experience with that medium), we wanted a tool that;
- captured an idea as an action quickly
- was usable on the go to make it easy for users to demonstrate the capability of the app to others, and thus make it easier to onboard them to join a contract
- fits the hypothesis that our users base would start with millennials and Gen-Z, which are the greatest consumers of mobile software by far
- fits with the lean product methodology as mobile has a higher tolerance for very focussed tools, which is what our MVP would be Making the app mobile soon became the obvious choice to achieve our goals.
Deriving our user metrics from our user goals
With considerations for the platform, and for the business domain in mind (legal tech), here are some of the actions that became clear imperatives early on.
We saw the app as a means to collaborate with other end users so meaningful interactions on the platform became our key metric. This meant that the engagement-first model — more synonymous with other social media apps such as Facebook and Instagram — which measure the length of time spent on the app and level of engagement rather than the quality of the interactions, would not work for agreeme.
We wanted to encourage:
- Short response intervals (tracked in minutes): How long it takes for a message to be acted on my the majority/entirety of its participants.
- Short transition of contracts to ‘locked’ state (tracked in minutes/hours): The length of time it takes from the creation of a contract to be agreed by all participants.
- High customer conversion (tracked as a ratio): ratio from free to paid customer
With our goal being to build a domain-specific control pane, we established some early principles as part of our quality control.
Enforce clear and predictable behaviour from the app (zero learning time or die)
Don’t overcrowd the user. Deliver new information in the appropriate context and only ask for new permissions in a ‘just in time’ fashion where the user understand its value
Ensure that a feature does not interfere with collaborative behaviour
Support uniqueness and additional features in a way that does not sacrifice clarity on the app
We want this, and the rules to follow to support our success metrics, to help build a delightful experience that promotes re-use.
Things we have learned — so far
Shipping software for mobile forces us to deal with some intrinsic constraints.
- More competition for attention and less focussed sessions
- Less real estate to inform the user of the available functionalities
The process also made apparent to us how much relevance there is in Marshall McLuhan’s famous theory ‘the medium is the message’, which meant being on mobile on its own communicated something about our product. The number of low-quality apps may still have some people consider a mobile app to be more of a toy than a tool or being a source of entertainment over something that could be genuinely useful. We have run a lot of internal conversations that have led to laying down some foundational hypotheses and our current approach in our UX plans.
They tended to relate to the following:
- how users can misinterpret aspects of the app
- how specific language and the notion of time can help people discover how to make the app work for them
- how the app could be potentially gamed for nefarious purposes it was never intended for
As we move through the project, we will inevitably encounter different elements of the app that work well, or not so well, and features or aspects should be reworked or removed in order to enable a better user experience. As part of this ongoing process, we will be exploring different ways to monitor these, even when un-reported by users.
As Hemingway said: “The only kind of writing is rewriting”, I might revisit this article or expand with more as we expand our early thinking and go through more discoveries.
Thank you for reading this article, I hope you have enjoyed it. As always, your feedback and suggestions are welcome at hey@olivier.is.