The first priority for the design was to define the authentication flows, including login, registration and forgot password. For this we sketched flow maps and iterated until landing on the right approach. To aid this process we created interactive prototypes that simulated what the user would see at every step of the process. Because we were more interested in the interactions than in the look and feel of the application, we used simple wireframes. This kept us focused on the flow, eliminating discussions about branding that weren’t relevant yet.
With the authentication flows defined, developers started to work on the implementation. During this time, our design effort turned to define the overall look and feel of the application using the Style Guide Driven Development approach - where a style guide is built as part of the application to drive the design and development process. Design decisions were documented in a living style guide as the styles were written, so as developers implemented the front-end, the application design fell into place naturally.
With the UI requirements covered by the living style guide, we decided to use Behavior Driven User Stories to communicate UX requirements. This approach focuses on describing the requirements needed for a feature from the user’s perspective, adding details that would be traditionally left out by simple user stories and yet are critical for implementing and testing a feature.
Behavior Driven User Stories describe: 1) the scenario the user is in, 2) the actions the user can do in the given scenario, and 3) the outcomes such actions will trigger. This made it easier for the developers to understand and implement the user flows because they were more aware of the intended design. QA engineers also used them for testing user scenarios. This approach was also effective at filling gaps in the design. As our designer was documenting the interface, they had to break down each one into every applicable scenario, revealing areas that weren't accounted for. Overall, using behavior driven user stories was an efficient approach for our team to collaborate on the design and implementation - making life easier along the way.
As a platform where high-value assets are held and traded, Equibit understands that going the extra mile for security is key to building consumer confidence in it's product. The security features implemented in the Equibit wallet reflect a philosophy of minimal knowledge of sensitive information: The server should never receive user passwords and should refrain from tying addresses to user accounts except where necessary.
In Equibit's wallet, passwords are validated on the client side by signing a challenge token from the server. Even if the network channel can be decrypted by a third party, no password or reusable login information is broadcast over it. Working closely with the Equibit core development team, one Bitovi developer implemented this strategy from scratch in about 6 weeks.
While trades of assets must tie users to Bitcoin addresses for legal and practical reasons, users still maintain privacy protections for any transfer and management of assets that do not involve public securities trades, even if the entire database is leaked to hackers or investigators. No keys are held in the clear on Equibit servers; transaction signing and key derivation are done exclusively in the browser. Addresses are only stored on the server as part of trade offers, so any other addresses found on the blockchain cannot be identified to relate to any user in Equibit. As an ongoing concern, Bitovi developers are careful to not introduce features or implementations which would threaten this privacy protection.
A key innovation on the Equibit platform is the "atomic swap," or the ability for two parties to trade assets that sit on two different blockchains, without one party being able to exploit the blockchain's lack of knowledge about either one. The key technology enabling this is the Hash- & Time-locked Contract (HTLC), in which each party first locks assets on the two blockchains and then collects the other party's assets. Below is an example conversation of how two actors named Alice and Bob might communicate a hash-locking trade in plain English:
But if either party can't complete the transaction, or the secret is lost, those assets could never be spendable again. To protect against this, a time lock is added to each of the locking scripts that lets Alice or Bob collect refunds from only the assets they themselves have previously locked.
Because of the importance of users seeing this process through to completion, our team focused on ensuring that the presentation of information is current, polished, and easy for users to understand. Despite the size and complexity of this feature, our team converted a technical demo of the underlying transaction construction into a complete feature ready for user acceptance testing in three months.
Bitovi’s expertise allowed the Equibit Group to built a feature rich application in the blockchain that is scalable and maintainable. The next step is to complete additional features that will further empower issuers and investors, such as passport restricted trades, in-app communication with investors, and the ability issue, manage and pay distribution to shareholders.
Contact us and let's create something amazing.