-Try making the chameleon 50%-75% smaller. It distracts from the content.
-I would eliminate the "Sign up with Huey" hoverstate. My first question was literally, who is Huey? I now know it's the name of a plan. If you leave it, the default plan should be Iguana, the recommended plan, and not the most expensive one.
-Currently the product comes across as too generic. Add a few more screenshots and use-cases to show off the uniqueness of your product.
-The support and sign-in buttons are too transparent. To draw attention to them, they should probably less transparent and have a solid text color.
-The product may be too barebones for the prices you are selling at. Try adding more features like voting for the best version, adding annotations, etc...
Huey is actually the name of the chameleon - but I guess that doesn't quite articulate that. Will have to find another way to do that.
Huey is also the name of a plan, so I can see how that causes confusion.
In terms of the price, I am not really selling on features - yet - but more on the benefit. I used to have this problem - i.e. managing multiple designers, with stakeholders all over the world - and I would have paid those prices to solve that problem.
That being said, I do intend to possibly add cheaper plans in the future - but I need to get the core problem solve and get some real customer feedback from paying customers.
Also, given that it is just me right now, I can't realistically support a ton of users - so we will see how it goes.
The pricing looks like it's based on the idea that, since designers and agencies are earning boatloads of money anyway, taking just a tiny slice of that money shouldn't faze them, even if that tiny slice amounts to $100/month. I think you'll run into a lot of potential users who will question the fairness of paying that amount of money for what is in essence an image viewer, and refuse to buy even if they could easily afford it and clearly see its usefulness.
That criticism is very valid, and if I do find that happening - then I will definitely have to re-evaluate my value proposition.
The main issue was that I know in my mind, what my revenue targets are - and I figure it might be easier/better to reach those with fewer users (mainly because it is just me right now, and I can't support TOO many users) and be better able to support those, than to try and get more users and everybody's support suffers.
I also thought what would be fair for me to pay - in my previous jobs, for this service and that is reflected in the price. Had I been doing what I used to do, I would pay these rates.
However, if the feedback is overwhelming that the price is too high, then I will definitely re-evaluate it.
I appreciate your candor about pricing. I am going through a similar problem and came to the same conclusions that you did. It would be interesting to see statistics regarding the prices that you charge and if you increase/decrease them. Also, when you do get paying customers, what percentage of customers are in each pricing plan.
Just an idea, why not also have a free 1 client, 100mb account?
I would think that this should get you some good user feed-back (past a 7 day usage pattern), and also eventually force users to pay up as they get more comfortable with your app.
I fought with this, to be honest. I know it can get more people into the funnel. I guess the issue I was afraid of - and decided to try and mitigate - is having to support a ton of free users, when I really need to get revenue coming in through the door.
Once things settle down and I have a nice core set of paid users, then I might consider doing that.
Who knows...this is just the first step, so expect lots of iterations from here on out :)
My professor once said something to the effect of "You sell something for free when you're combating the anxiety of loss. You don't go free to compete on price." I guess one thing you have to ask yourself is if your customers aren't coming because they're afraid of losing something, even with the 7 day free trial. I don't necessarily think you need a free version. Also, it's easy to decrease prices but difficult to go up.
I agree with some of the other posts that suggest you should add some more illustrations of what the product does. Sitting in my armchair I don't see the difference between this and a flickr album besides being able to post 4 pictures side by side. I'm not your target audience though so I don't know what problems your customer segment has.
I think I will definitely be adding some more illustrations and such.
The difference between this and a flickr album is that this is made specifically to get feedback from clients - whereas flickr is made to display images.
Sure, they both display images - but both have different purposes.
You understood what I was getting at. I would have offered the free plan to get the app polished (post 7 day usage pattern I described) but if your not exactly ready to field support issues that flood in, it could hurt a tiny bit.
I would add more images and examples of the application in use.
Also, choose more relevant examples... the only one I see is a comparison between the same image with color changes. Show something like a whole website project from early stage (sketched mockups) to later stages (details in coloring and font choices, or whatever).
Also, IMHO, the copy should focus more on the benefits for the designer (get better feedback faster, more often) than on the benefits for the client ("Save your clients the hassle of resizing browser windows, or printing...")
This is a great looking app and site, especially if you were learning as you went.
Thanks very much. It's been a whirlwind trying to get this out the door. Now that I have done that, I can take a step back and focus on the finer things, like copy, etc.
I really appreciate the feedback and that makes total sense. I was trying to get that with the headline: "Designers: Get feedback. Simply."
Congrats Marc. Really glad to see to see compversions launched. Beautiful design. Played with the app, really great; Especially the UX (it's terribly simple and straightforward)
That was by design. A little hack to get the behavior I wanted out of Rails. Rather than doing something else like 'marketing.html' or whatever, I tried to stay as close to the default as possible :)
I'll bite with a few guesses. What are you getting around with this routing hack?
Assuming you are using Devise with the conventional HomeController, and 'root :to => "home#index"' you shouldn't have to bother with faking a resource in the url. From your /login page, your logo links to /home/index anyways. All the hashtags/anchor tags should work. I've not had a problem with it myself.
The headers for /index.html return the same 404 resource as /adjhasdkj123123, so I'm rather curious. Teach me something. :)
The main issue was that I didn't want the user to just see compversions.com/home/index when they are logged in.
I wanted them to see compversions.com.
If I have index.html - as far as I found anyway - in my public directory, all requests to compversions.com (logged in or not) will either redirect to compversions/home/index or compversions.com/index.html.
So, as far as my research told me at the time (remember I am just learning Rails still, so I could be wrong anyway) was that if I wanted logged in users to see compversions.com when they are logged in and on the root_path, there couldn't be a index.html, otherwise Rails routing would default to index.html.
This looks interesting, but not sure it will do what I need - which is having Rails re-route requests to index.html or root_path based on if they are logged in or not...or am I missing something ?
Doesn't solve your problem directly, but it's a nice way to have static pages in your app in a manageable way.
You'd want to do something along the lines of what they show in the override section and test for your authenticated session within the controller, branching appropriately.
I didn't design it - from a graphics perspective. I worked with two awesome designers who worked with me to craft it....i.e. they put up with my overbearing demands :)
I dont have a need for this day to day, but I was going to sign up to get updates, check out the tool etc.
Since I dont hvae a use for it today, I figured i wouldnt really use the 14 day trial.. What I really wanted was a free version so I could come back and use the tool when I had a need for it in my daily life.
I fought with this, to be honest. Many people have requested a free account, but the issue I was afraid of - and decided to try and mitigate - is having to support a ton of free users, when I really need to get revenue coming in through the door.
Once things settle down and I have a nice core set of paid users, then I might consider doing that.
Who knows...this is just the first step, so expect lots of iterations from here on out :)
I find the pricing structure a bit odd. The "Chameleon" pricing plan seems to have no incentive to buy. For the same exact thing you cant get 3 "Gecko" plans and save $50 ... or get more by buying two "Iguana" plans?
One tip for pricing, make bigger plans cheaper per unit.. so let's say a unit is a project, your base 1 unit price is $4.90 (with a minimum of 10 units)
so your 20 unit price should let you pay less per unit than $4.90, ie. it should be less than $98.
Whatever you set it to (say $80) means your new per unit price is $80/20units = $4. so for your 30 unit price, it should be less than 30 * $4 = 120..
You need to provide an incentive to move to the next pricing level, and the best way to do that is to make the higher levels have more relative value than the lower ones. You work out the "value" by working out your per unit price.
iguana and gecko look good, but chameleon and huey are a bit off..
chameleon gives you 50% more storage and clients than iguana, but costs way more.. $132 would give it about the same relative value, but it's $158..
I'm ignoring the number of clients cause I don't believe $26 is a good price for 5 extra clients. maybe it is, but it's a lot less clear to the end user.
I am not a designer so I have zero use for your application, so take what I say as coming from a non-customer.
1. Congrats on charging up front.
2. Your price barrier feels high, you attempted to make it easy with a 7 day trial, you can try a 1 project 1 client, 20 file free account that you can try to up-sell if you have trouble demonstrating your value (I'm a non-customer, so hard for me to judge). 7 days feels short specially with design projects.
3. Move the blood sweat and tears comment in the footer to an "about us" type of page.
4. Move support from an e-mail to you to a FAQ page with a "didn't answer your question, contact us form" to avoid getting too many repeat e-mails.
I didn't want to make the price too low, because I am not sure how many users I can realistically support right now (given that it is me alone). That's also why I didn't do a free account.
Can you give details on how you boot-strapped and learned rails. What did you use to learn rails, what did you find best/worst, what was your development background prior. What confused the hell out of you / helped you most, etc....
-The semi-transparent chameleon is clever
-The pricing section is well-designed
-Product looks simple and easy-to-use
Stuff to consider:
-Try making the chameleon 50%-75% smaller. It distracts from the content.
-I would eliminate the "Sign up with Huey" hoverstate. My first question was literally, who is Huey? I now know it's the name of a plan. If you leave it, the default plan should be Iguana, the recommended plan, and not the most expensive one.
-Currently the product comes across as too generic. Add a few more screenshots and use-cases to show off the uniqueness of your product.
-The support and sign-in buttons are too transparent. To draw attention to them, they should probably less transparent and have a solid text color.
-The product may be too barebones for the prices you are selling at. Try adding more features like voting for the best version, adding annotations, etc...