Product Design - Freelancer
2019-
gigable.com
Like in any other new product, validating the idea and the proposed business model with stakeholders was one of the initial challenges. Feedback was collected before a first version of the app was developed.
A MVP was launched and it featured hundreds of gigs and more than a thousand people interested in working up to this date. Some issues were then evident (navigation, hierarchy, technologies used) and new questions were raised prior the development of a stable release of the product.
• Would the usage be recurrent?
• Would users trust on the app to provide their bank details?
• What would be the best approach for notifications, filters, nudging?
• Would users trust on the app to provide their bank details?
• What would be the best approach for notifications, filters, nudging?
• How much data do we need to ask on registration?
• etc.
• etc.
Structure
I started by mapping the structure and the flows of the current app and proposing alternatives to solve the main issues and to better accommodate the features that were being planned on the roadmap.
• Sitemaps
• Sitemaps
• Cardsorting
These are some of the issues we wanted to address:
• The most prominent navigation button was to switch from "Helper" to "Owner" (and vice-versa), which is a infrequent action.
• The users defined their availability and the type of work they were looking for in their profile, in a bureaucratic and static flow.
• The most prominent navigation button was to switch from "Helper" to "Owner" (and vice-versa), which is a infrequent action.
• The users defined their availability and the type of work they were looking for in their profile, in a bureaucratic and static flow.
These options have then become simple search filters, which could be saved and trigger notifications.
Some metrics we have in mind
• % of users who complete the registration
• % of users completing their profiles
• App usage recurrence
• Gigs registered / time
• Gigs that have candidates
• Number of candidates per gig
• Number of gigs done (and paid) / time
• [Future] Organic referrals (code, share)
• Revenue
• % of users completing their profiles
• App usage recurrence
• Gigs registered / time
• Gigs that have candidates
• Number of candidates per gig
• Number of gigs done (and paid) / time
• [Future] Organic referrals (code, share)
• Revenue
Benchmarking
Competitors and related products were analyzed in this process, which helped us to have different perspectives in solving key issues of both structure and flows.
Prototyping
Wireframes were developed and quickly reviewed. Sketch's built-in prototyping tool was a quick way to build a clickable prototype and present the new flows.
Discussions at this stage have also turned into changes to the sitemaps from the previous step.
Discussions at this stage have also turned into changes to the sitemaps from the previous step.
UI/Visual Design
Designs were then produced based on the wireframes. 'Helper' and 'Owner' will still use the same app, but from quite different perspectives. Navigation, colors, and the way information is structured reflect their different goals and use cases.
An original requirement was to use Ionic and its cross-platform components. However, this technology was used in MVP and it wasn’t performing well on some devices.
Work in progress
The development team decided to rewrite the app in React Native. All screens are being adapted to use the new components before I start writing the detailed specifications and hand them over to the developers.
As seen above, in the design process of this new version we found out that it would be essential to change paradigms in key features to move forward. In addition to having to assess the risks of a potential impact on the users learning curve, more radical changes like these do not fit well into the iterative model we see as ideal for testing individual ideas. For the product, it is often better to "change tires on a moving car" than to replace the whole car from time to time.
Looking for a middle ground
We knew that some anticipated changes are more critical or urgent and others carry a higher level of uncertainty. In order to reduce risks and reduce the gap between the two versions, the development has been split into two fronts:
• Improvements in the current app based on what was thought for the new version; validate
• Development of this new version, iterating over it as we get feedback and learnings from the releases above.
• Development of this new version, iterating over it as we get feedback and learnings from the releases above.
Thanks for watching!
