Inclusive design for awesome and effective business.
We build brands, strategy, communication, products, services and experiences.
We have interviewed three farmers in the Rotterdam area and designed a farm management prototype application. The mobil software app allows farmers to analyze their herd and milk robots via sensors that gather data for KPI's and helps them organize daily work tasks.
Work examples coming soon,
let's wait a while...
Vedett Beer, part of
Duvel Moortgat breweries, commissioned us to design a little summer treat for promotional purposes.
Click here for more
We came up with 'VEDETT RAKETT', a simple flavored water ice-cream based on their iconic bottle shape.
concept & design by topika, sourcing by sapion.
Recently we (
Alexander Zeh and
Peter Robinett) were asked to come up with a design for the interface of an Android tablet app for a mobile payments system to be launched in East Africa. Specifically, we were asked to develop mockups for the screens an agent would see when taking cash deposits from new or existing users.
Click here for more
The Problems With The Original Deposit Scenario
We were asked to present designs for the account deposit flow of an existing customer, in which an account holder deposits cash into their account via an agent using the agent tablet app. In the usage scenarios provided to us, deposits are posited as follows:
- customer visits agent and registers if necessary
- customer enters his phone number on the agent’s tablet
- receives a login code by SMS
- customer enters login code on the tablet
- customer selects “cash deposit” operation and enters amount
- customer optionally enters recipient’s phone number
- (if depositing money on behalf of somebody else)
- agent takes cash and validates transaction with his PIN code
- (customer is logged out automatically)
- customer (and optionally recipient) receives SMS
- confirming new credit and account balance
Treats the agent tablet like an ATM
The interaction flow outlined above in the usage scenarios document has a mistaken interaction model in which a user controls the agent’s tablet. This is similar to an automated teller machine, where the user also logs in, selects the deposit task, and then deposits money. This ‘stateful’ design, where there is a user logged-in state on the tablet, creates a mixed interaction in which the agent is rendered superfluous during much of the interaction while still hovering nearby, only to be required at the end to take cash and validate the transaction. However, the user’s interactions do not have the freedom of occurring on a separate, stand-alone machine as would happen with an ATM.
Trusts agents too much
Customers should authorize fully-specified transactions, not preemptively authorize them by ‘logging in’ to the agent tablet at the beginning of a transaction. The latter creates the possibility for abuse. For instance, suppose a customer logs in and enters all transaction information and then hands the tablet and cash to deposit back to the agent. A dishonest agent could then quickly alter the specified recipient or deposit amount and authorize the deposit with his PIN, robbing the customer and leaving the InnTrans system none the wiser.
Trusts customers too much
In any country tablets are desirable products and frequent targets of thieves. This is especially true in poorer countries where they will be especially. Their portability, value, and use independent of the InnTrans system makes them easier and more attractive targets than traditional point of sales systems. For instance, this Nigerian TV report shows an M-PESA agent being robbed, with the attackers stealing approximately €1600 in cash and goods: [http://youtu.be/tWpP6XL54kk](http://youtu.be/tWpP6XL54kk)
Not only will the tablets used by agents be desirable devices in their own rights, but a thief with access to the encryption keys stored on the device may be able to preform fraudulent transactions. For these reasons, we fear that an interaction flow which requires customers to handle the agent’s tablet machine is an unnecessarily risk. While physical restraints such as a Kensington lock would help, safer would be to simply keep the tablets in agents’ hands behind their shop counters.

How did we redesign it?
We see the user deposit interaction flow as best described by a request- response cycle, where the a deposit action is requested and there is a response with authorization.
It’s is not the user who makes the request: it is instead the agent.
This is so because it should be the user who authorizes a transaction, even a deposit one into his or her own account.
The reason for this reversed flow is both a matter of simplicity – an agent can more quickly enter a user’s despot request than a user unfamiliar with the agent app’s interface – but also of trust.
Wireframe 1
The Agent selects the Deposit action button under the Customer Transaction navigation tab.
Components
1. Customer Transaction navigation tab
2. Deposit action button
Wireframe 2
The Agent fills in Customer information
Components
1. Phone number
2. Amount
Wireframe 3
The input fields validate their content
Components
1. Request deposit
Wireframe 4
Service sends all request info via SMS to customer with a confirmation code
Components
1. Progress wheel
2. Notification
Wireframe 5
The request is stopped because the Customer does not have an account, the Agent registers the Customer in order to resume the deposit process
Components
1. Start the registration process
Wireframe 6
The Customer is recognized and a transfer ID returned to Tablet.
Agent confirms cash hand over and transaction via a code that the Customer received via SMS.
Components
1. Transfer ID
2. Customer information
3. Customer confirmation code
4. Agent PIN
Wireframe 7
The agent confirms the transaction
Components
1. Confirm the transaction
Wireframe 8
Confirmation of deposit (SMS)
Components
1. Progress wheel
2. Notification
Wireframe 9
Transaction pending
Components
1. Updated list item
