November 26, 2017

Rip my landing page to shreds, please

Hey hackers!

I know we have a good number of these posts going around at the moment but I wanted to add one more 馃檲

If you have something out right now that you're looking for feedback on, please let me know in the comments here, so I have that little notification in the corner bugging me until I get a chance to look at your app/project/thing.

I just put up version 1.0 of the landing page yesterday for that I'd love feedback on.

I've been documenting every day's work on my blog, and I wrote a bit about the land page yesterday [1] and laid out my idea on the day one post [2]

But the gist of it is: I'm scratching my own itch here. Coming from a support engineering role, one thing that stuck out a ton is how many customers write in when presented with a user-facing error message (alerts, toasts, validations, etc) And understandably so, given that the error messages that we write for our own programs have varying degrees of usefulness.

Any how, I started to obsess over the cost of these errors:

  • Cost in support hours

  • Cost from users abandoning their tasks (your features!)

And began looking for ways to measure the cost this has by reducing lifetime customer value. This lead me down a manual audit of all the errors in our codebase at my old workplace, and cross referencing that to support tickets etc.

It was clear we could get some big wins by tracking the visual errors that we make, rather than just tracking client-side JS errors and server-side errors that fill up our logs. And using this new visual error tracking to A/B test error messages, to recover from their costs.

Whew, I cannot keep posts short 馃槄 Sorry about that, but thank you so much for having a look!



  1. 3

    Hey modette

    My quick feedback:

    1. To me, "losing money" speaks more to somebody in finance / business person. I believe the most likely person in an organization who would champion adding this service would be somebody in a technical / engineering or support role. And for these roles, I suspect "wasting time" is a larger pain point than "losing money" (although they are roughly equivalent in a theoretical sense).

    2. I was hoping for more background on the errors in the screenshot. In particular, desktop vs mobile, operating system, and browser.

    Good luck with it!

    1. 1

      Thanks mgowski!

      1- You're so spot on here. In part of my validation attempts I've been trying to discover if my most likely champions are: support, UX, or product managers/business folks. Any you can see the mix of messaging on the landing page 馃

      I'm a/b testing audiences over the next few days using some cheap ads on linkedin etc (I can buy cheap adds for larger volume than my organic traffic now)

      I'll definitely take this feedback into account. I imagine I'll land on targeted landing pages/copy for each superset of suspected champions.

      2- Hmm! I was wondering how I might ad more content at this stage (pre-early-access) without feeling like I'm forcing fluff out the door 馃槀 We're you looking for more visuals, or a bit more details on the story side of the error?

      Super appreciate the comment! Cheers

      1. 1

        I don't think it's a matter of adding "more" content.

        It's just that for support issues one of the common factors is something not working as expected in a particular browser or platform. As soon as I saw that not being present in your screenshots I kinda dismissed this as something I would consider further :(

        Just my 2 cents....

  2. 2

    Looks good overall. A few nitpicks...

    1. "Stop losing money to your error messages" - I like it, but can be a bit more clear. "Stop losing money to your application errors"?

    2. "You already test call-to-actions to make money, we help you test errors to save money" - this can be modified to show more value IMO.

    3. The application screenshot needs to be a bit more crisp

    4. An indication of possible pricing might help folks decide to sign up

    5. The content looks a bit cramped. Needs more white space. I think it's the line spacing (I'm visiting from my desktop)

    6. I see a white strip below the footer when I scroll to the bottom

    7. I like how you talked about yourself at the bottom. I wanted to do this for my project's landing page too, but I thought it makes more sense to keep the focus on the product. So I ended up putting a link in the footer to my site. I'm on the fence about this one though.

    8. the email address text in the footer doesn't have good contrast with the footer background

    9. Not sure about the red colour on the CTA, but I see it's part of the brand, so it makes sense. May be A/B test it?

    1. 1

      Hi maheshj 馃憢

      Thank you for taking the time to have a look and comment!

      I love every item on your list, ad what follows is a long reply of how I plan to test (as soon as I have time!) or leverage your feedback.

      1- Great point! I'm a/b testing headlines with ads right now (ads are cheap enough at this stage to test at a far greater scale than my organic traffic)

      I'll throw some variation of this into the mix.

      1. 馃 I'll need to let that sit stew in the back of my mind for a bit. But I certainly agree, different headlines need to be tested here as well

      2. Cheers, I'll work on getting a screenshot that edits down into a higher quality/crisper image.

      3. Yes! Adding pricing + an option to preorder is on deck for today/tomorrow. I'm getting a fair number of signups for a b2b saas landing page that's only been around for a little over a day, but I'm concerned that having pricing on the page now would help as a filter and set expectations. I'm glad to hear this from you!

      4. A few folks from Medium mentioned whitespace. I shall get on that!

      5. I haven't been able to reproduce this with the footer yet 馃檲 May I ask what browser you're on? I'd like to get that taken care of.

      6. I definitely get that! On previous projects I didn't include an image/blurb about myself. But my thought process here is: until I have customers in a closed beta, I don't have any social proof or testimonials to leverage. And people (mostly!) like people. So I'm hoping introducing myself helps provide some trust.

      7. Roger that, totally agree, will tweak the color

      8. I milled this one over for ages. The red CTAs on the white/gray background does bug me 馃槸 There's a lot of research out there in support of blue and then green for CTAs. I think, as soon as I'm able, I'll add A/B testing those colors into the mix.

      Whew! Sorry for the long response. And thank you again!

      1. 1

        Happy to help... 馃檪 My comments...

        (2) Food for thought - the problem for me with the subheading is that it's not impactful. The first half of the sentence is unrelated to the product (You already test call-to-actions to make money). So it loses impact. The line is also a little redundant considering that you already talked about losing money in the main heading. I'd rather speak about the problem I'm solving or a few core benefits that I'm offering

        (4) I think having the price on the page does 2 things - 1. clears the expectations for the visitor, 2. if the visitor signs up even after looking at your pricing, then it's a validation (if not too strong) that people are willing to pay

        (6) Weird, not seeing the footer issue now. I'm visiting on Google Chrome on MBP

        (7) Yes, that's the reason I said I'm on the fence about it. To build trust, you need to talk about your credentials and what makes you expert enough to solve the problem. Maybe talk a bit more about the problems you faced because of which you are building this? It's good that you composed it to feel more "human" by mixing your work and interests but to me, it feels like a description of a team member on the careers page of a company (sorry if this is a little harsh).

        1. 1

          2- Hmmm! Thank you for that I'll keep brainstorming here!

          7- No worries at all on being too harsh! That's great feedback, I'll also try to highlight some of the problems from past experiences there. I think that's a great feedback, needing to carefully balance the conversational tone and professionalism here.

          Cheers again! 馃槉

  3. 2

    It looks good actually, especially the captions at the top.

    Here's a few things in no particular order:

    1. The sticky header is a little annoying, especially on mobile.

    2. Nothing immediately jumps out as to why this is any different/better than Why would I switch from Sentry to this?

    3. You're collecting email addresses... so ideally you need a privacy policy. Not that anyone will read it, but it looks more professional even to just have the link in the footer to it.

    I'm just nitpicking really... the landing page looks goods to me.

    As someone who already uses Sentry, really the best thing you could do is make it easier to troubleshoot the errors.

    Sentry just dumps a stack trace at you and leaves the rest up to you. I'm not sure how you would make it any easier, but if you made it easier to troubleshoot the errors it would be quite compelling.

    Also, I'll take you up on your offer for feedback for my side project please. You can see it here:

    1. 1

      Hey Harley!

      First, thank you for taking the time to comment! I really appreciate it!

      1. Noted! And looking back at the landing page after stepping away for a bit, it does seem unnecessary. I'll start testing (as soon as I have time) with that menu removed. I'm getting early clicks and signup conversion the CTA on desktop in the menu. But not on mobile 馃 Thanks for the nudge there!

      2. We use sentry and log entries at the company I most recently worked at too. Love both.

      So where I'm hoping to come in from is instead of focusing on just the errors that get logged from our applications (client-side JS errors and server-side errors) I want to focus on an easy way to track our own errors that we write for customers to see. Which are often a byproduct of the clientside/serverside errors.

      Logging like sentry lets us track new errors and helps a ton with finding the source of an error (or the exact PR, just looking at a graph on sentry for the origin of an error has help us find a PR to revert when things really hit the fan)

      I'm hoping to expose the layer of what our users are doing when these errors happen. How often does an error message we present lead to a customer contacting support? How many times does a particular toast/message lead to a user abandoning a task, and how does that change their lifetime customer value. What resources and copy can we change to make actionable errors that help and educate when possible.

      I'm also using mutationsobservers to help back this up. It lets you replay a user's exact session to see what they did after running into an error -- to help UX/support/engineering? make a decision on how they can improve their customer-facing error experience.

      So, It's a (strange) mix of analytics, UX, and our A/B testing own error messages/validation messages. Kind of the tracking this UX consultant blogs about here:

      1. I for sure do need to put on up. It is on the list, but the last 24 hours have escaped me. But no excuses! I will get that done today.


      Sorry that ran so long!

      To your point #2, I'd lovvveeee your feedback on my above response if you end up with some time! I know, coming from having used sentry and similar tools, I'll have some trouble painting the picture of how Bystander is looking to help alongside those tools.


      On to

      First, you didn't warn me this was a game 馃槀 Now I'm trying to win an offline match but failing.

      So, everything just works great.

      The only "gotcha" I ran into (even though I read the rules and should have known better!) I after picking up a piece, and changing my mind, I clicked on another instead of clicking back on the original piece. Which correctly swapped the two pieces, but I think I have a pattern stuck in my head of clicking on another piece lets met set down the current one and pick up the other one.

      Obviously the swapping is a feature not a bug in your case. But maybe a warning the first time a user tries to initiate a swap? Just for a one-time touch to train them.

      But I'm just trying to find something to pick at here. It's hard to make a game that you can just click into and understand right away, but you've done that here.

      Maybe out of scope, but I wonder about spectating any games that are going on?

      1. 1

        Thanks for the feedback, I've taken that on board.

        Back to your response... that sounds quite good. But the landing page doesn't convey that. As soon as I saw all the copy around "errors" I just immediately assumed it was going to be like Sentry. Perhaps that's just me misinterpreting it, or perhaps it needs to be spelled out in a way that's quick to understand... ideally with a picture or something.

        And even if I had been able to understand the uniqueness of the product, I'm still not exactly sure how this would work technically. The page mentions dropping in some javascript, but what then? Do I need to wire up every error manually? If so, why couldn't I just do that myself with google analytics custom events? Or is it going to work automagically? If the latter, that would be very impressive, but it sounds like quite the engineering feat considering everyone writes their own custom error logic.

        So I guess 2 things the landing page needs...

        1. I need to understand in 5 seconds or less why this is uniquely compelling to something like Sentry.

        2. I need to understand in 5 seconds or less why this would be worth it from a technical point of view.

        But probably this kind of approach only makes sense if you are targeting developers.

        1. 1

          This is very valuable feedback thank you!

          I've definitely been struggling with the language used here, "errors" is a bit broad but I can definitely see how I'm sending off sentry-ish vibes with the current state of my copy, especially coming from a developer/engineering background 馃

          Right now (although I know it's really early so this data will likely not be overly valuable) my signups look to be in the ballpark of: 60% developer, 20% customer support, 20% user experience.

          My first assumptions, which are super naive assumptions this early in the game, had engineers at 10-20% with UX being my biggest audience. TL;DR I definitely need to keep iterating on copy to help get my message on point and present my uniqueness.

          With those three segments being so different, I'm leaning towards landing pages targeted towards each (ux, dev, cs)

          In your case as a developer, do you think an image to help get across the kind of errors in place of my dashboard screenshot would be more valuable?

          The engineering of the clientside library has been a ton of fun. So, to get up and running with tracking your error elements/messages and tracking sessions to "replay" a users actions after they run into an error, it's as simple as loading the library with an array of the CSS selectors that can target your various error containers.

          The current (early) version is loaded like:

              ".form .error"

          This will listen for dom creation/destruction, css visibility, and viewport visibility. And stream actions once a user runs into an error -- debating on tracking N actions at all time so we can store a certain number of user actions leading up to an error too. There are, of course, edge cases I still need to take into consideration and a lot of testing to do. I've plugged the library into quite a number of site (just running it client side to test the actual detection and tracking, with mocking the stream of data) to make sure the proof of concept is workable. I imagine there are some fringe stacks I won't be able to accommodate.

          A/B testing your error message's content (similar to the gif and lower screenshot in the third section of the landing page) is too brittle to work this automagically. So, similar to Segment or Intercom where you're tracking an event and need to place a small snippet of code, at this time, I'm looking at requiring an id-code on the error element. So an error message for being "unable to save a user at this time" might look like: <div data-bystander-error-id="1007">the error message</div>

          ID'ing customer facing error messages is a pattern some organizations do already, so I do accept existing custom ID attribute names when loading the library, so if a team already places an id in the dom for their errors they don't need to repeat work here. If not, I hope my github integration will (ultimately) make it easy for non-engineering teams to communicate down to the engineering team which error messages they want to A/B test, so they're only adding and ID as-needed instead of front loading a lot of work.

          And of course this may all change as I gather feedback and test further 馃榾 I feel terrible that I keep sending a wall of text your way 馃檲 But I care about your feedback a lot and you've given me a ton of food for thought, so thank you!


          I tabbed back in to Monsiv again earlier and had another random thought (I'm just throwing out ideas as they come to mind here!)

          Reading the "how to play" I think a staged game that gives you just enough moves to walk through each pieces movement, swapping, win & lose conditions, would be great (tooltips to help explain the next action we're taking?)

          1. 1

            Having separate landing pages sounds like a great way to go.

            And that code you've posted above is a really smart way to do it. The developer landing page should include that code snippet front and center to prove to developers how easy it to get setup and running.

            Also call the library Bystander. "UserError.load" is boring, but "Bystander.load" is branded and also on a technical level, less likely to cause namespace issues.

            As a totally non qualified comment I think you should just get the core concept out the door and worry about other features like A/B testing later on, if and when people are actually asking for it.

            As for the landing page targeted at non developers... I think you should definitely have one, but I don't know what it would look like. You need to talk to non developers for that :)

            And thanks for the further feedback about Monsiv... that's a great idea, I've added it to my hugely long list.

            1. 1

              Cheers, thank you again Harley. Your comments have been incredibly insightful, and I have copied all this down into a spreadsheet to start organizing and prioritizing here 馃槄

              Spot on with calling the library Bystander. Skipping the A/B testing feature until its needed/requested is something I'm giving a long hard think about now that you mention it. It's easy to start with a core idea, and let my doubts start to pile on feature XYZ to make this valuable.

  4. 2

    A quick scroll through, it looks good.

    I would double check some small wordings in the copy like:

    "Stop losing money to your error messages" to "Stop losing money from error messages".

    Small tweaks like that.

    And if you have a case study where you can prove it, add that link in there.

    1. 1

      Hey! I too love the soothing voice of Bob Ross 馃槀

      That's a great point, and to vs from is something I just wouldn't have seen without your nudge. I'm actually a/b testing headlines starting last night, and I'll do some tweaks and throw this into the mix as soon as I have time! All the copy could use a little love 馃檲 I'll keep iterating, cheers!

      I definitely want to add a use-case/testimonial. At the moment, all I have is my experience from my previous role, where I accomplished some of what Bystander is looking to do, but by performing a manual audit. But using my own experience outside of Bystander's context feel dishonest to me? I'm hoping to leverage early adopters to fill this gap a soon as possible. But I'll give this a good hard think to see if I can come up with a more near-term solution.

      Really appreciate the feedback here! Thank you 馃槉

      1. 1

        Yeah, Bob's the sneeze.

        Do a 2-week experiment for someone for free.

        You want the asset and they want a tool that will help them accomplish X.

        Then write the case study.


        1. 1

          I'm face palming so hard right now. That's the winning strategy for sure. That will be an excellent tool my email outreach over the next few days too.

          1. 1

            Sweet. Now get pumped with this information and go run through a brick wall. You got this! 馃檶馃従