Designing Blockchain D-Apps, Part 3: Design & Specification
This is part of a series of articles exploring how to design decentralised apps (D-Apps) using Ethereum. Part 3 of this series covers Design and Specification and is designed for Product Managers.
As part of our exploration of blockchain we’ve been learning the nuances of creating D-Apps, from inception to QA testing. This article is designed to act as a recording of the process, for anyone attempting to follow the same path. If we have something wrong, inaccurate or out of date, let us know in the comments!
By this point we had set several broad points of specification:
- Concept — The D-App will focus on Peer-t0-Peer lending of books (as we had them to hand and could play out the scenarios easier), allowing a transaction between a Owner and a Lender of a book without the need for a centralised arbitration from a library, where the book Owner can hold an escrow of the Lenders funds until the book is returned.
- Technology — The D-App will be built on Ethereum, using Solidity for a Smart Contract, with a Bootstrap front end for the UI, with no use of traditional centralised databases, unless locally stored
- Goal — The D-App must place something on the blockchain, via a smart contract and retrieve it, to be considered complete
- Definition of Done — The D-App must be usable on the Ethereum testnet to be considered completed (a very loose definition of done)
Developing the Specification
We took a traditional approach to defining the User Experience, developing simple personas and user stories. Then modelling them over a single scenario and expanding this into corner cases. We defined the following user stories :
The Owner — owns the book
- I want to be able to add a book to my collection, and list it for loan, so that I may lend it to a Lender
- I want to be able to record books that I have out on loan and for how long, so that I can easily keep track of who has my books and when they were lent
- I want to be able to set an escrow sum for lending each book, so that I can protect my investment
- I want to be able to provide my public key to the smart contract, so that if the book is not returned, I can claim the escrow funds
- I want to be able to set a time limit for each lending period, so that if the book is returned late, I can take a portion of the escrow funds
- I want to be able to mark a book as returned, so that I can release the funds from the smart contract to the Lender
The Lender — lends the book
- I want to be able to review the books in a owners library, so that I may choose one to lend
- I want to be able to place funds in escrow, so that I may lend a book from the owners library
- I want to be able to mark a book as returned, so that I may receive my escrow funds back
At the time, these seemed a like a simple set of stories to begin with. However on reflection, we didn’t cut the functionality down enough to cater for our first move into using a relatively new toolset. But more on that later.
We spent a little time exploring the concept more, but eventually settled on a simple single user flow, that looked a little bit like this:
As we developed understanding of the use-case, we began to highlight some corner cases that required design decisions:
- What happens if the book isn’t marked returned by the Owner?
- What happens if the book is damaged on return?
At first we tried to tackle these issues as if we were building a “real” application with a partner. Closing flaws in the logic and identifying new user stories to prioritise. However, over time, we decided that it was probably better to follow the phrase:
“Is it slightly better than lending a book to someone without the D-App?”
In which case, the corner cases were greatly reduced and we could pursue the real purpose of the project — building something fast, to learn.
The UX design was completed simultaneously with technical explorations. As the team became more familiar with the concepts of Ethereum and Solidity, more detailed questions began to emerge (some very dumb ones too), that influenced the design further.
Once the UX and Technical Designs were completed, we undertook a very brief UI design phase. As the specification called for a front end built in Bootstrap, this was less “creative design” and more “information architecture”.
Overall, we revisited these designs several times as we cut back features, but tended to work directly in HTML. One of the joys of working in Bootstrap is its limitation and simplicity to deploy components, which saved us a lot of time and allowed the team to focus more on the technical challenge of a Distributed back end.
As with any agile project, we worked iteratively to solve problems and adapted along the way. For this project more than others we made major revisions to the functional specification, cutting back heavily on the original functionality. This was mostly driven by technical challenges of a new technology and over confidence in the planning phase.
Changes we made:
- Removed duration of lend thus overdue/late returns — the concept of lending for an amount of time added complexity we couldn’t ship within the allotted sprint time.
- Removed payments — figuring out best practice for payments proved complex, so we dropped the feature to ensure we shipped on time. We plan to resolve this in a future sprint. This also meant cutting all the related features, such as late return fees.
- Removed the Lender UI interface — Once the features above were removed, we rationalised the UI to a single page app. If the D-App develops, we’ll definitely revisit this and develop a more user friendly set of interfaces.
Changes to UX Flow
An overview of the changes to the User Experience Flow.
Changes to Technical Design
An overview of the changes to the Technical Design.
Changes to UI Design
An overview of the changes to the User Interface Design.