This is the first of (hopefully) several installments in which I will log my process of designing and developing a new product. I’ll start with the very first concept and end… wherever it ends. I have two reasons for doing this. I hope my foibles are interesting or informative to others, and I also suspect that forcing myself to write what I’m doing will make me more thoughtful and introspective about my own process. My plan is to continue updating this “log” for as long as the project is active. Comments or suggestions are always welcome.
Part 1
The Problem
My partner is a reputable tattoo artist. She works out of her own shop primarily. But she also visits other shops occasionally and works for a while as a guest. This is fun, but one of the challenges is that it can be hard to predict whether there are enough interested clients to justify the cost of the travel. This is the problem we are trying to solve.
The Solution
I thought: “what if we could reverse the process?”. Instead of setting up a trip and then hoping that enough clients sign up, why not wait until enough clients sign up and then set up the trip? The idea is for her to advertise the places she’s interested to visit and let the customers “vote” by somehow announcing their interest. This is the basic idea for the what I’m now (tentatively) calling Road Show. Sometimes I make very customized solutions for a very specific purpose, and that is the only situation it needs to work. For this project, I decided in the beginning that I wanted to make a solution that would work for a wide audience, not just other tattooers, but maybe traveling professionals in other industries as well. So I spent some time thinking about the most effective “vehicle” by which to deliver this solution.
By some estimates, WordPress powers 30% of websites on the internet. I’m very familiar with WordPress development and, conveniently, my partner’s website is built on WordPress, so I decided that a WordPress plugin was a sensible format. The plugin would extend WordPress to allow professionals to list places they are interested to go/work along with some mechanism for the site visitors to offer their contact information as a “vote”.
The workflow I imagine is that the traveling professional lists places he or she wants to go, along with a corresponding number of clients that make each place “worth it”. And I expect this number to be different for each place, probably corresponding to how much someone wants to go there and perhaps the cost of traveling there. So for example, someone who loves the beach might consider visiting Hawaii in the winter even if there are only five clients, but only travel to Alaska for at least thirty clients. Someone else might feel the opposite. If it works, we will be able to gather a list of potential clients before any travel commitments, and hopefully the clients might be motivated to recruit their friends in order to make it happen.
Does This Already Exist?
Making things can be a fun and rewarding experience even if it doesn’t ever generate income. But if my goal is to somehow profit off of the work, important questions should be asked. Not least of which is: Does this product already exist? This is closely related to “Has this problem already been solved?” If the same thing I plan to make already exists, does the world need another? If something else exits that solves the same problem, is mine meaningfully better? I spent a couple hours searching https://wordpress.org/plugins and couldn’t find anything that looked like my idea, but this is hard because the idea is a bit abstract and could be described with a wide variety of terminology. Although my initial “customer” is a tattooer, I want my product to be widely applicable to any professional who might travel to where clients are. Musicians, speakers, healers, etc. Eventually I found a handful of calendar / booking plugins that seemed like they might include the functionality I wanted to provide. In past projects this is where I might have stopped. But in an effort to be more thorough, I installed them in a local WordPress site and confirmed that they, in fact, did not do what I was planning to make.
The Wireframes
So after doing a little homework, it still looked like there was a good reason to make this product. So now it was time to think about how it should actually work. From the beginning, I had a vision of an interface with a selection of places that users could interact with and submit their contact info. This is a nice idea, but it’s not a product yet. I need to figure out how it will really work. To get there, I put myself in the shoes of a tattoo client looking at the website. What information does the user need in order to understand what’s happening? What do I need this user to do? And what does that user want to do? In this case, the user wants to get a tattoo eventually. What I need is for the user to tell us that by entering an email address so we can schedule them when the time comes. It would also be helpful for the user to understand that their engagement actually makes the trip more likely to happen.
At the beginning I like to work fast and loose while I’m figuring out “the gist” of how it should work. How fast and loose? This fast and loose!
By quickly scribbling these rudimentary interfaces, I explore the way the text interacts with the arrangement of the content to direct the user’s expectations. I try to remember to look at it through the eyes of a user who is just seeing this screen for the first time.
I put a lot of thought into the exact call to action. It’s important for the user to understand that they are being invited to participate, and “vote” for the trip. But I worried about the risk of implying any sort of commitment that might deter clients from engaging. A later version of this tool might include the option to collect a deposit or even pre-pay for an appointment, but for this early version I don’t want to scare anyone away by making the language sound too committal. The idea is to first build the list of prospective clients, then later when there is enough interest to justify the trip, email them all and see how many are prepared to commit.
I wondered if it would be more intuitive to present the prospective trips along with confirmed travel dates.
This direction would have resulted in a more traditional interface as you might see for a band’s tour dates. But I decided against it because it felt too passive and seemed to demote the importance of the user’s interaction.
In an attempt to keep things simple, and not get too fancy too soon, I decided to start with some simple text explaining how it works. And then a list of clickable place names. The next question was what should happen when the user clicks that button?
What is the “MVP” or What do I NOT need to build?
I considered a few different ways to architect the interaction. Ideally, the tool would keep track of which clients “voted” for which place. And then perhaps provide an easy mechanism to email them all. So I considered building a custom form that would appear when the user clicks the place. But this would involve a lot of extra code to handle the form submission, error states, the admin interfaces, etc. And at this stage we don’t even know if users will even use this. I thought about hacking an existing form plugin, but even that seemed unnecessary before establishing whether users will actually interact with this concept at all.
After a lot of deliberating, I decided to keep it really basic and just use a simple mailto: link which will initiate an email from the user’s default email client. The subject and the body will be prepopulated with all the essential information, so the user can just click “Send”. In this way I sidestep all the hassles associated with email delivery. But it still solves the same problem because the user has provided their email address by sending an email, and the subject line contains the name of the place they’re voting for.
Of course, this means that the site owner has to manually keep track of the emails received for the various places. This is annoying, but it’s not that hard to do. And if it does become too much work during testing, I consider it a “good problem” because it means that the experiment is working. As soon as we get to that point, then I’ll build the extra interfaces and store the submissions in the database.
Another important bit of functionality I’m not building yet is any functionality related to the question of how many clients need to sign up to a given place before the trip is worth it. I have big ideas about ways to “gamify” this so that clients are motivated to recruit a few friends in order to fill the quota. But this has to be done thoughtfully and probably with a bit of customization for it to work on a wide range of sites. So I’m setting this aside for now.
Version 0.1
After a lot of head-scratching and a few hours of programming, I came up with the most basic, stripped-down version of this feature that could possibly get the job done. I wrote a simple WordPress plugin that defines a custom post_type and a shortcode to display them. For this version, the shortcode produces a barely-styled <ul>, which works just fine but isn’t very exciting. My partner wasn’t keen about that aesthetic, so I spent a few more minutes extending her site’s theme to add some style for the new feature.
You can check out the code that went live on GitHub. The plan is to publish this and see what happens. As soon as something does, I’ll follow up with more.