01 — Product design
Re-imagining contracts
Create, organise, and re-use digital contracts for Lonely Planet. Manage its lifecycles, and enable team collaboration when editing.
Overview
Lonely Planet is a travel-guide publisher in print, and digital. They have been loosely dubbed as “backpackers’ bible”, and has covered most of the world’s travel destinations. To achieve this, they commission articles from their established pool of travel writers. In effect, this means hundreds of contracts to make and negotiate.
We introduced 4 main features: documents storage, contracts editor, fill-in-the-blanks data, and compare-approve workflow.
Documents storage
This feature collects all the contracts in the system; organised by folders, and different statuses.Contracts editor
Main course of the project. This enables collaborators, and editors to create contracts from scratch or update existing contracts.Fill-in-the-blanks parameters
This allows editors to recreate contracts by filling up different data on selected parameters on any template.Compare-approve workflow
This feature enables reviewers to compare added content, giving them indicators on what has changed, and with the ability to approve or discard it.
I was responsible for the over-all design of the product. I was also able to introduce features that weren't initially added like the Compare-Approve workflow.

Dig in
I got to work closely with the product manager, and engineering. I was sent and assigned in Brisbane, Australia while under a funding program. I was responsible for the over-all design of the product. I was also able to introduce features that weren't initially added like the Compare-Approve workflow.






I had fun designing on this project...however, the product was ambitious with its outcome, and timeframe. We offered features and tried to develop them on a tech stack that was advanced for our engineering capacity back then.
Results
I had fun designing on this project. Documents editing is a big space, and I admit there’s still a lot more to add, and improve in this project. However, the product was ambitious with its outcome, and timeframe. We offered features and tried to develop them on a tech stack that was advanced for our engineering capacity back then. We were able to create the editor to some extent, but failed to its performance after some pages. It was then decided by the client to proceed with the document storage only on its production.
Key takeaways
- Not everything you designed would make it to production, and that is fine. Take all the learnings you can.
- Documents management is a growing space, and there is a lot of fun, and useful features you can introduce.
