Information and Communication Technologies for Development

Yesterday we had an interesting discussion at our weekly team meeting.
As we are getting into more detail about how Mosoko interface will actually work. We debated what are the implications in terms of cost, programming complexity and customer experience, the key question from our discussion was:

- How do we balance the browsing vs searching capability of the interface.

On one extreme case would be to ask people right up front what they are looking for, conduct a search in the postings database and get back to them with the query results. The main drawback from this approach is that the query will have way too many matches, that would make the search results irrelevant. Although it would be very neat from the user perspective just to call Mosoko and mention 3-4 key words to conduct the search, this means a short call time and lower air time cost for Mosoko.

On the other extreme case we can push users to drill down through browsing trees until they narrow down their search enough to make the search results relevant. For example if someone wants to buy a mountain kid bicycle in Nairobi for under $20, the user would have to drill down the browsing menus and choose: -> Buy -> Kenya -> Vehicles -> Bicycle -> Mountain -> Kid -> Under $20. The drawbacks of this approach are: the process takes too long, which firsts pushes air time costs up and second frustrates users. It also increases the complexity and rigidity of searching trees structure, which may be difficult to scale up when users start exchanging items in new categories.

Once we have a deeper understanding about the interface and the database search capabilities, combined with the cost structure we will be able to craft the 'best possible' solution.
One that balances a good user experience, with a simple and scalable interface at the lowest possible cost.