This work is confidential, please do not share.
Overview
Since launching in 2009, Threads has been on a mission to make outfit envy a thing of the past. From sourcing rare pieces to refreshing your wardrobe, no request is too big or small for the Threads’ Personal Shoppers.
The Shopping App is a tool for Personal Shoppers to broadcast their clients' desired ‘hard to find’ items to a network of contractors (called Sourcers) to find these items.
Brief
Produce an app that will move the sourcing process from WhatsApp to its own designated platform, which will allow the sourcing function to scale and provide the business with important information regarding the sales timeline and client interests.
Details
Company:
Threads Styling
Position:
UX/UI Designer
Location:
London
Users
The Shopping App has two user groups, the Personal Shoppers and the Sourcers. These different users need to work together collaboratively to achieve the goal of obtaining and selling an item to the client, but their use cases are very different.​​​​​​​
Personal Shoppers have to create a request detailing the item their client wants and once it’s sourced they need to either accept or decline the price that’s been provided. While the Sourcers need an organised list of requests they can sort through so they can decide which items they will try and source. Once they have successfully sourced an item they have to inform the Personal Shopper of its price, secure it and then have it delivered to a Threads hub.
All the Personal Shoppers are internal Threads employees, while the Sourcers are mostly external freelancers with a couple of internal staff members.
Product Challenge
The biggest challenge for this project has always been getting users to adopt the new platform and move away from WhatsApp. It is always a struggle to get users to switch from one product to another, especially when they are very familiar with the original, but there is an extra challenge when the new solution doesn’t have an initial obvious benefit to users.
WhatsApp allows Personal Shoppers to very quickly send a request to a Sourcer and it’s highly flexible with the information it lets them provide. There are no mandatory fields or list of options they have to go through, they can just send a photo and state the required size. This is a valid user experience for the Personal Shoppers, and even for the Sourcers if they have a small number of requests and can remember who they are from.
The problem is it’s not scalable. If there were hundreds of requests being sent it would be unmanageable and the risk of sales leakage would be high. Also, if the number of freelance Sourcers expanded across the globe it would be difficult for them to be properly utilised if they’re not on anyone's contact list.
So, while a designated sourcing platform may remove some of the flexibility from the users, it does provide an environment for structured information which is much easier to process for a growing user group. It also allows the business to record and analyse the items clients are interested in and the effectiveness of the sales funnel.
Design Challenge
From the start the Shopping App would be split across two apps. The Personal Shoppers would access it through an existing app they used to catalogue client details and create sales orders, as they were familiar with the product and much of the required information was already stored there. The Sourcers did not have an existing product so a native iOS version of the Shopping App would be created for them.
The app the Personal Shoppers would be using was already a number of years old and had not had a UI update for a long time. While the new iOS native app would need to follow the current design system which was much more modern (the hope being the existing app would eventually be updated to the newer UI).
This created the challenge that there were two versions of the app with very different design systems, so each would need to be considered when designing the initial version of the Shopping App and every iteration or new feature added after that.
Process
Research
The initial research included user interviews to get a much better understanding of the existing sourcing process and any pain points they had. This was beneficial to learning the end-to-end journey the Personal Shoppers went through from receiving a client’s message, to making the sale and having the item delivered. We could also see the information required by the Sourcers and the importance of clear communication between both parties.
There was a similar fashion sourcing app available at the time called Sourcewhere, which was
a useful example to see how the flow between the different users would work and the kind of interface involved to make the process as efficient as possible.
Flows
The Shopping App’s user flow is a back and forth between the Personal Shoppers and Sourcers.
If a client has already paid for an item the flow becomes considerably shorter as the Sourcer can go ahead and secure it, without needing Personal Shopper permission, as long as it’s less than the total client spend.
When freelance Sourcers were introduced to the app we also had to extend the flow to include a shipping form feature so Sourcers across the globe could have items delivered to a Threads hub.
Sketches
Despite having two user groups the Shopping App doesn’t have many screens. At its core there is the create request form, a list view and request detail screen. The inputs for the two users will be different but the majority of the information displayed is the same.
Testing
Over the 14 months of working on this project an extensive amount of testing has been conducted, this included regular contact with 7 Sourcers and 18 Personal Shoppers. This involved surveys, workshops and user testing prototypes. Much of the feedback received was positive from both user groups, with regular comments about how easy the app is to use, with a clean interface and simple navigation.
However, due to lack of adoption, many users still preferring WhatsApp, there was feedback stating it was difficult to communicate with other users via the Shopping App. There was messaging functionality but as users were not checking the app regularly they would not see or reply to messages. This was more of an adoption issue than a design one, but became a recurring piece of feedback. The solution to this was to try to increase overall adoption of the app by better promoting its features and highlighting its benefits to the users.
There were also requests for a desktop version of the app, but due to prioritising other projects this has yet to be implemented.
Mockups & Prototypes
After conducting some initial tests with the UX sketches and having a strong understanding of what users and the business wanted, work began on creating digital mockups of the app. These designs allowed us to start constructing a visual style, which followed necessary design systems, and helped users and stakeholders better evaluate the screen layouts.
The mockups provided a clear visualisation of how users would interact with the product, helping to identify potential issues, refine the user flow, and ensure that the design aligns with the project's objectives. At this stage we were also able to create high-fidelity prototypes for user testing and to share with developers.
Click the links to see a prototype and the design system.
Product Iterations
Once an MVP version of the Shopping App was released we were able to test the live product and see how it was used in the users typical working environments. We learned that creating a request needed to be done much faster to compete with WhatsApp.
Another learning was that allowing Sourcers to claim requests for themselves was blocking the sales pipeline, as only they had access to a request other Sourcers could no longer see it. To solve this problem we moved to a model where multiple Sourcers could save a request and whoever sourced it first would move on to the next step of the process. This approach decreased the average time to source a request by 9 times.
Additional Features
Since the initial release there has been a number of new features added to the Shopping App.
A location feature was added so Sourcers could say when they would be in specific stores. Sourcers could also add the receipt for their sourced items to speed up the purchase declaration process. Freelancers were given the ability to arrange for their items to be delivered to a Threads hub as they were less likely to be in the area.
A lot of focus was placed on making the Shopping App as fast to use as possible and reducing manual workloads.
Results
A complex sales process turned into a simple to use work tool. Battled low adoption initially, but after inviting freelance Sourcers to the platform, there was an initial baseline of 4 out of 28 Sourcers using the app, which has risen to 10 out of 28 - a growth of 150%.
There are currently 27 Personal Shoppers using the app with an average of 32 requests created each week. Typically 24% of requests are being sourced in 2.5 days.