15 comments

[ 4.4 ms ] story [ 30.4 ms ] thread
Side project I've been working on for a while. Would love feedback from a design stand point (landing page) and a 'do you see enough benefit to use this' perspective.
I found FAQs are typically a symptom of a poor design or UX layout.

Do you find a lot of people are going through and trying to read FAQs in app?

(looks good, just curious about how many end-users would use it).

Yes, but often you can't fix the poor design because your app is part of a bigger system that you can't fully control. In that case a FAQ might be helpful.

(Also, unfortunately, the importance of good documentation is often overlooked nowadays. People keep talking about intuitive experiences, but what is intuitive to one person might be puzzling to someone else. In some cases, good documentation could be an important differentiator for your product.)

I tend to agree for most questions, but feature requests and longer explanations are still useful IMO.

For example, I have an app that allows you to send postcards from your iPhone in which I get several emails a month asking if things can be shipped internationally. It's fairly explicit in the UI since it's for US style addresses, but I also plan on adding international shipping soon.

I have another app that lets you lookup the name associated with a phone number. I get 5ish emails a month asking what 'No results' means. The FAQ is helpful in explaining why this might be the case (skype numbers, burners, etc) that is hard to do in a constrained UI.

Just some examples of how I use the side project myself. Easier to try to answer the questions up front, while I keep refining the UX, than put in an hour a month on support.

My MX Records were boinked last night when I switched to a new DNS provider, so I've been unable to receive any emails in the last 24 hours. If you sent me an email please try again (sorry about that)!
Think you may need to add a bit more about the technology involved..how easy to integrate, that sort of thing. Is this a component for iOS, or..?
I don't get the value proposition. Why would I use this instead of just using a web view that shows a page from my website?

The only reason for using a service like that is for quick low budget iPhone apps, where I want to give clients an easy way to update the FAQ. But your landing page doesn't show what the admin interface looks like.

Also, I believe that monthly pricing won't fly for your audience. This is only interesting for low budget projects, and you usually don't have an ongoing budget to pay for stuff like this. You'll have to make it a pay-up-front solution.

I think this would work better as a component on one of those component marketplaces, and with instructions how to host the FAQ on your own server.

Totally agree. Why would somebody who can code implement a service that allows you to integrate a simple view? Why would anybody pay for that? Why would you pay somebody per view? So many questions.
Thanks for the tough feedback, I'll definitely mull it over. One of the reasons I made this was because I have multiple iOS apps in the App Store that are really just fun apps that I don't have time to support. Since they don't have websites or server side components, something dead simple like this makes a lot of sense.
I think the "Developer" tier has the most promise as a selling point. For apps you just want to get out there, I think some developers would be willing to pay 4.99 to quickly slap on a FAQ section. The reasoning might be "I'll do this for now, and implement my own solution later". Being able to update the FAQ instantly would be very important at first and is definitely worth 5 bucks. Very cool stuff!
Design feedback :

1) Great name.

2) Font, image quality look good.

3) Looks okay on mobile. iOS Chrome the hamburger overlay font color is too faint, background bleeds through the overlay too much and distracts and obscures readability.

4) YOU NEED to have a FAQ menu in the top bar there. C'mon.

Cost benefit thoughts :

1) When I saw 499 I immediately thought the following :

A) Typical "enterprise" price point.

B) A single free instance on GCE/GAE can do 2 million static views a month. Why would I pay 15 USD a day to do that ?

2) Contrary to the detractors, "of course" this is worth the benefit, so long as you make the cost low enough. How low is low enough -- well, if you say pay 2c per view ( 499 ), sure I get that it makes sense from the model of :

-- Customer acquisition < 10 USD

-- Custom support, on ramp costs, < 10 USD

-- 2c per view to cut onboarding costs, FTW!

However, for developers, your main audience, 2c per view doesn't work from the following model:

-- 5 million views per month ( say 2 paid GAE instances )

-- 10 GB outgoing traffic

-- 730 GB memcache

-- 2 GB doc storage

Total GCE Calculated Estimate : ~ 60 USD a month.

Estimates at : https://cloud.google.com/products/calculator/#id=341a6f6c-8a...

Why would I pay you 8x that ?

Developers think like this.

Finally if you feel the work load for you of serving 2M views per month is going to justify 500 / month per customer, it works to have a more efficiently scalable workflow, or a lower personal burn, or higher growth ambitions, or all three!

Thank you for the extremely detailed feedback, much appreciated. I'll admit that I haven't really thought about the 'enterprise' portion of the offering, instead featuring on the small time developer. This is a great breakdown of what might happen in an enterprise developer's head, I'll need to mull this over as well.
(comment deleted)
This is a great project Matt. We're working on similar things at UserDeck [1] and I think mobile support is going to be huge. I think you're getting a lot of feedback that may be a demotivating as HN has a lot of developers, but not many business minded people which is what I've found is who you sell and the developers implement it based on the needs of the business.

For example on the build vs hosted service there are many things a developer would not want to build such as WYSIWYG, analytics (figure out what is working, what isn't), ratings (up/down), easy changes (no app store deployment), translation across devices (iOS/android), ticketing (contact form for help). When I had initially thought of similar ideas, Zendesk hadn't moved an inch, but here lately they started getting into mobile support [2] so if anything I find it validation to the market that will just continue to grow. There simply is no reason every developer should build all of that out reinventing the wheel when there can be a service to provide that functionality and focus development resources in other areas.

If you want to chat more, my email is in my profile.

[1]: http://userdeck.com

[2]: https://developer.zendesk.com/embeddables