I'd like to be able to check it out, but there is nothing on the page describing the tool. The next best thing would be to check it out using a fake email, but I cannot confirm from the fake address.
While it might make sense to verify email addresses when the app is in full production (but probably does not), when the goal is to get feedback, putting friction into the process is (at least in my case) counter productive. At the very least, I am going to switch browser tabs to process the email and then wind up on another page to confirm it before I get back to looking at what I wanted to see. In between...well...I've got Hacker News open and there's probably something more interesting there than dealing with email and thinking about the possibility that I am signing up for spam. And that's about the best case for using an email sign up.
All that for an email address rather than usage data about the product. I know email addresses have some value, but the valuable addresses are those of engaged users and an email address != a user (let alone engaged user).
My random advice is to consider what problem email signup solves for potential users and whether or not it drives away the kind of users that might be good for the site.
Actually it is in full production and the goal is to get feedback so that's why it's completely free. The email needs to be verified as this is the address you'll receive contact messages from your created website, thus the need to be correct. It's not about the value but not to send emails to an incorrect address. I have set it to confirmed so you can proceed.
Thank you. There was no way for me to determine that the project status is more than an email harvester with above average effort at design.
Maybe placing email entry and verification into the relevant technical context might make that clearer. It would also keep users on the page longer, by which I mean that even the legitimate need for email and verification entails: Taking the pure gold of someone who has actually landed on the site and sending them somewhere else to conduct an unpleasant administrative task. Now the caveat is that I hate email in general because my inbox is a todo list of things I have not done (at the very least I have to process everything in it). There are exceptions for actual conversations, but that's not what a confirmation email is.
Oh, I get how boring this is but the decision was to take the boring part out first and allow the users to later focus on the real process! Anyway, noted and I'll try to think of another solution!
The product is quick and easy to use...even if my grandpa's use case probably doesn't match any of the three primary options :). The aesthetics are tasteful.
My design advice is to get rid of the part that is unpleasant to the maximum extent possible. That's what good design does. It's one of the things Hacker News gets right.
How useful are email updates with static text versus a dashboard that can slice and dice data? Sure some people will want email because that's the way they have always done it. Some people will want email updates because it fits their use case. But everyone won't so it can be opt in.
Or to put it another way, it's not clear that most people will have the problem that email notifications solve or at a finer grain, that the problems that come with email notifications are less painful than the problems that email notification solves.
Riffing a bit...email notifications could be an upsell. The conundrum I encounter with free platforms is investing time in building something when there is not an obvious revenue model.
The revenue model is simple in this case. For everyone that wants to use a full website (custom domain, analytics, no attribution), a small price is worth it. Adding the notifications on the dashboard is the next step but for now receiving it directly was much easier and instant. I think any grandpa would love to receive contact emails! Haha... By the way you had me worried that it looks like an email catcher website and added a features page. Hope this is a good step but anyway, you are the one to blame!:-P
Haha! I think we do! As instantly as a website can be created wouldn't fit there! But seriously now, instantly refers to the publishing process and not the account creation one. You just fill out your account details, a few important settings and two-three fields and you create a fully functional website that can receive emails, subscribers and can have multiple pages. Sorry if I mislead you!
I mean to move the requirement for signing up until after they have built with the tool. Take them directly to the builder, and when they want to save their progress - ask them to login.
That would have been a good thought, but when started, we decided to go with the classic approach! Thankfully, this additional friction hasn't had any significant impact to conversions! Anyway, thanks and it's something I'll keep in mind for future versions or projects.
While it might make sense to verify email addresses when the app is in full production (but probably does not), when the goal is to get feedback, putting friction into the process is (at least in my case) counter productive. At the very least, I am going to switch browser tabs to process the email and then wind up on another page to confirm it before I get back to looking at what I wanted to see. In between...well...I've got Hacker News open and there's probably something more interesting there than dealing with email and thinking about the possibility that I am signing up for spam. And that's about the best case for using an email sign up.
All that for an email address rather than usage data about the product. I know email addresses have some value, but the valuable addresses are those of engaged users and an email address != a user (let alone engaged user).
My random advice is to consider what problem email signup solves for potential users and whether or not it drives away the kind of users that might be good for the site.
Good luck.