In this article I’m going to briefly cover how to harness bad design decisions strategically. Specifically — how to plan for and use organized chaos to move quickly, learn and deliver a high quality end result!
Theres really two types of software designers: those who make bad decisions and those who know how to break the rules and when to strategically make bad decisions to arrive at good work. Just like in nature, it’s very difficult to immaculately conceive of a perfect design, release it into the wild and expect it to not get torn to shreds by customers. A better strategy is to evolve the design methodically over time, learning as you go and arriving at configurations unexpected yet exceptionally resilient out in the marketplace.
I’m a mobile app designer and founder at Retrographic ( Sprocket Bicycle App ) and formerly Lyft, SoundHound Inc. and a few other notable places over my +10 year career. Today I’ll be using my own bicycle apps sale item header design as an example for how to land a successful longshot over multiple iterations by leveraging feedback and data.
So what the hell are we talking about here? Whats your app again?
Sprocket is a bicycle marketplace I started thinking about after how many people, including myself, got into cycling during the last 2008 depression. Specifically it was hard to figure out where and how to get started and I got scammed on the first beater bike I bought. This app connects buyers and sellers in your surrounding community so that you can get over the hump and find a good deal on your first set of wheels! Its a two sided marketplace so we’re going to talk about several years of evolution of the interface the buyer sees when they look at bikes for sale on the platform.
The first version didn’t actually have an interface. To test the idea of selling bicycles I integrated with eBay Partner Network and just showed affiliate links to their bikes. This immediately gave my platform a near infinite amount of bikes to connect potential new riders with and relied on eBay’s UI to contact the seller or buy them.
Another version of a bike sale page I had at this point was a ‘bicycle factory specification’ page on the Android app. While it was not an item put up by a seller it shared a lot of the proto-UIX with current bike sale items and described the default specs/parts the bike came with.
Oddly the first bicycles I decided to build for sale on Sprocket were those in the database. In hindsight a laughable decision, because it basically excluded everyone who came with a bicycle to sell and could not find a match in our database. This looked like so:
I realized my mistake pretty quickly based on customer feedback and built a new sale item into the app which we call the ‘custom bicycle’ in effect letting sellers create a sale item with whatever data they wanted. In this way we were no longer impeding them from listing their ad with us.
You can see a couple interesting things in this Play Store -like version. For one its basically an amalgamate of that early database factory spec layout and the eBay price+buy button UX. Also embarrassingly in this version the app and server did not support taking and storing images yet so what you see is actually coming by hashtag through the Instagram API from some random photographer unrelated to the sale.
At this point you may be asking yourself what does the ‘Make an Offer’ button do?
It basically takes you to a terribly designed screen for entering your counter-offer and questions to the seller by email via our server. This way the seller gets a guaranteed layer of privacy and can choose which offers to respond and engage with.
A couple things occurred at this point. I started selling my own bikes through my app and noticed how inefficient the back and forth conversations are over email. I also started to see people put their phone numbers directly into the notes field and ask to be contacted that way. I made a hypothesis that basically some people preferred phone-text over email and that if I provided an opt-in for this I could increase the efficiency of transactions on my platform, and therefore revenue.
The advantage was that the button was now wider and you could contact people by phone or text. The problem was you couldn’t actually see who had a phone-text option on for their sale and buyers new to the app probably could not tell it was an option at all. Sellers continued to put phone numbers in their descriptions…
I did not have a solution for this problem but I did have an idea for how to improve the tappability of the UI, legibility of the price and provide an added level of validation to sellers from my experience with Lyft’s rideshare order UI.
An interesting moderation problem cropped up with this improvement. A large amount of people started sending me support emails that read like they were asking questions to a seller. I concluded after writing support emails for about 100 of these that they’re probably ‘not ready to make an offer’ and are using the ‘feedback’ button to ask the seller questions.
Meanwhile in another part of the app I had set up federated authentication through several providers. The pill buttons there looked clunky and their text inappropriate for their function. I removed the text as I continued adding more provider options into a kind of efficient button grid.
Once I realized these circles could work to represent different methods of authentication I realized they could also be used to represent different contact methods in a more discoverable way!
By applying this new design I made it internationally clear that these tap targets were different communication methods in a way that did not need text, and most importantly did not dictate how they should be used. The report button while currently ugly as sin now makes its function clear as something that reports the sale to the console and is explicitly not a communication method to get in touch with the seller. I can validate this design works because my time writing support emails to questions about bikes went down to zero!
What did we learn?
As you can see it was not really possible to project into the future and predict what features this platform would need and how its userbase would try to use the interface to do business. An interface is really an ongoing conversation between the service and its customers. By adopting existing interface elements from elsewhere as a baseline the system was able to become quickly operational and start receiving feedback. This feedback at every turn instructed the evolution of the interface to meet a more defined set of expectations and project requirements — some of which are unique to this specific application. In this way we were able to figure out a way of thinking and push beyond industry standard elements to craft something truly unique for the Sprocket community not seen in many other apps. And this is how you plan to fail confidently upwards into a quality customer design experience.
By the way if you want to check out the Sprocket apps design and give me feedback or are on the market to sell or buy a bike you can check it out here:
🤖 Android
🍎 iOS
🌐 Web ( WIP )
Send feedback to seven@sprocket.bike or comment below 👇
