I definitely believe UX and typography are important, just lower priority than “site loads in a reasonable amount of time” and “get an integration/unit-testing framework in place to avoid mounting tech-debt”. Do you disagree with that?
It’s hard to know what to say here; of course the site should load in a reasonable amount of time (this other NN Group article is particularly relevant here)… but…
One thing I could say is—of these scenarios, which is best, and which is worst:
The site loads quickly, and it’s good.
The site loads quickly, but it sucks.
The site loads slowly, but once loaded it’s good.
The site loads slowly, and once loaded, it sucks.
Clearly, #4 is worst. We’d all prefer #1. But suppose we find ourselves at #4, and further find that (by the expenditure of some unit of time/effort) we can move to #2 or to #3—we can’t jump directly to #1. (Then, perhaps, we can take another step, with more time and effort, and make it all the way to #1.)
What I am suggesting is that #3 is the superior first step compared to #2, because (in no particular order):
The aesthetic usability effect (as described in the link above) ensures that poor performance is more readily excused if the site is perceived to be appealing; the reverse is not the case
Poor performance is more readily excused as a transitional-stage effect of a beta development stage than either poor aesthetics or poor usability
A visitor who perceives using the site as having high value but also high cost may retain the mental impression of “value here, but also high cost; questionable for now whether worthwhile” and come back to it (and keep coming back to it) later; a visitor who makes the snap judgment of “little to no value here” leaves and does not return
As per this comment thread, aesthetics and usability can often be (but are not always) easier to improve than infrastructure (i.e., separately from #3 being a better place to be, it’s also easier to get to than #2)
Of course aesthetics and usability and other aspects of UX (like efficiency and effectiveness of task completion) aren’t everything that go into making a site “good” or “sucky”, so what I said above is not the whole story; content, for instance, is largely (though not nearly entirely) orthogonal to both that and to performance per se…
As for “get an integration/unit-testing framework in place to avoid mounting tech-debt”, well, there is much to be said for doing that before starting a public beta; of course there is nothing to be done about this now. (Neither is there necessarily anything to be done about various technical decisions which quite complicate certain sorts of improvement; the fact remains that they do indeed have that effect…)
The problem, as I’m sure you realize, is that I, the user of the site, cannot see your tech-debt. Oh, I may quite clearly see the effects of your tech-debt—or, at least, you say they’re effects of your tech debt; how can I know? maybe some unrelated cause is to blame; I have only your word, here, and anyway it hardly matters why problem X, Y, and Z exists—they do, and that’s that.
So then you do your thing, to avoid mounting tech-debt, and—and what? Is the site now more usable, as a result? More aesthetically pleasing? Can I navigate it more easily? Does it load quicker? Well, no, those things will come, now that you’ve solved your tech-debt problem… but they have not come yet; so from my, user’s, perspective, you’ve spent time and effort and benefited me not at all.
So perhaps you’ve made a rational decision, following a cost-benefit analysis, to delay improving the user experience now, so you can more easily improve the user experience later. Very well; but if you ask me, as a user, what priority solving your tech-debt problem has, I can only say “zero”, because that accomplishment in itself does nothing for me. Count it as a cost of doing the things that actually matter, not as itself a thing that actually matters.
Viewed that way, the choice is actually not between the options you list, but rather between “improve usability and the user experience by improving aesthetics / layout / design” and “improve usability and the user experience by improving performance”. I spoke about this choice in the first part of the post; in any case, pick one and do it. If one of those things (but not the other) requires you to fix your tech-debt first, take this cost difference into account in your decision. If both of those things require you to fix your tech-debt first, then go ahead and fix your tech-debt. If neither of those things actually require you to fix your tech-debt first, well, that too is something to factor in…
At this point we’ve already made most of the progress we wanted on the performance and testing framework and the remaining work to be done is roughly on par with the “fix the easier to fix issues”, and hashing out the remainder here feels less valuable than just doing the work. I do think a case could be made that the easier stuff was worth doing first, but we made the decision to switch when it seemed like we’d make more rapid progress on the “easier” stuff after we’d fixed some underlying issues.
I do probably agree with the implied “public beta should have waited another month or something” (though with a caveat that many of the problems didn’t become apparent until the site was actually under a real load)
Thank you, and apology accepted.
It’s hard to know what to say here; of course the site should load in a reasonable amount of time (this other NN Group article is particularly relevant here)… but…
One thing I could say is—of these scenarios, which is best, and which is worst:
The site loads quickly, and it’s good.
The site loads quickly, but it sucks.
The site loads slowly, but once loaded it’s good.
The site loads slowly, and once loaded, it sucks.
Clearly, #4 is worst. We’d all prefer #1. But suppose we find ourselves at #4, and further find that (by the expenditure of some unit of time/effort) we can move to #2 or to #3—we can’t jump directly to #1. (Then, perhaps, we can take another step, with more time and effort, and make it all the way to #1.)
What I am suggesting is that #3 is the superior first step compared to #2, because (in no particular order):
The aesthetic usability effect (as described in the link above) ensures that poor performance is more readily excused if the site is perceived to be appealing; the reverse is not the case
Poor performance is more readily excused as a transitional-stage effect of a beta development stage than either poor aesthetics or poor usability
A visitor who perceives using the site as having high value but also high cost may retain the mental impression of “value here, but also high cost; questionable for now whether worthwhile” and come back to it (and keep coming back to it) later; a visitor who makes the snap judgment of “little to no value here” leaves and does not return
As per this comment thread, aesthetics and usability can often be (but are not always) easier to improve than infrastructure (i.e., separately from #3 being a better place to be, it’s also easier to get to than #2)
Of course aesthetics and usability and other aspects of UX (like efficiency and effectiveness of task completion) aren’t everything that go into making a site “good” or “sucky”, so what I said above is not the whole story; content, for instance, is largely (though not nearly entirely) orthogonal to both that and to performance per se…
As for “get an integration/unit-testing framework in place to avoid mounting tech-debt”, well, there is much to be said for doing that before starting a public beta; of course there is nothing to be done about this now. (Neither is there necessarily anything to be done about various technical decisions which quite complicate certain sorts of improvement; the fact remains that they do indeed have that effect…)
The problem, as I’m sure you realize, is that I, the user of the site, cannot see your tech-debt. Oh, I may quite clearly see the effects of your tech-debt—or, at least, you say they’re effects of your tech debt; how can I know? maybe some unrelated cause is to blame; I have only your word, here, and anyway it hardly matters why problem X, Y, and Z exists—they do, and that’s that.
So then you do your thing, to avoid mounting tech-debt, and—and what? Is the site now more usable, as a result? More aesthetically pleasing? Can I navigate it more easily? Does it load quicker? Well, no, those things will come, now that you’ve solved your tech-debt problem… but they have not come yet; so from my, user’s, perspective, you’ve spent time and effort and benefited me not at all.
So perhaps you’ve made a rational decision, following a cost-benefit analysis, to delay improving the user experience now, so you can more easily improve the user experience later. Very well; but if you ask me, as a user, what priority solving your tech-debt problem has, I can only say “zero”, because that accomplishment in itself does nothing for me. Count it as a cost of doing the things that actually matter, not as itself a thing that actually matters.
Viewed that way, the choice is actually not between the options you list, but rather between “improve usability and the user experience by improving aesthetics / layout / design” and “improve usability and the user experience by improving performance”. I spoke about this choice in the first part of the post; in any case, pick one and do it. If one of those things (but not the other) requires you to fix your tech-debt first, take this cost difference into account in your decision. If both of those things require you to fix your tech-debt first, then go ahead and fix your tech-debt. If neither of those things actually require you to fix your tech-debt first, well, that too is something to factor in…
Gotcha.
At this point we’ve already made most of the progress we wanted on the performance and testing framework and the remaining work to be done is roughly on par with the “fix the easier to fix issues”, and hashing out the remainder here feels less valuable than just doing the work. I do think a case could be made that the easier stuff was worth doing first, but we made the decision to switch when it seemed like we’d make more rapid progress on the “easier” stuff after we’d fixed some underlying issues.
I do probably agree with the implied “public beta should have waited another month or something” (though with a caveat that many of the problems didn’t become apparent until the site was actually under a real load)