Monitoring a site after launch (part 1)
February 6, 2012 § Leave a comment
A lot of effort goes into launching a project, but often they can be found neglected after launch. We see this more in client projects with a launch date, than with start-ups or any of our internal proprierty work, but the ideas here should apply to all.
It is niave at best, to assume that once launched the project is done – to this end we always encourage clients to budget for work *after* launch. Sometimes this can be a hard sell, because people assume that once something is launched it is done, however argubly this is the most important work to be done. Before launch you are essentially working on educated guesses and experience (or hopefully user testing), but after launch you can see how real users interact with your work and even ask them for feedback.
« Read the rest of this entry »
Don’t build that feature.
August 25, 2011 § 1 Comment
Are you building a new feature right now or are you building bloat? Please stop.
Seriously, I can’t be bothered to write yet another feature. At least not one that will spend 4 weeks to build out and then leave unchecked until a redesign/rewrite. Is this feature being used? Has it made an impact to the signups/purchases?
I want to know if people are using that search box i’ve added on products/show, or if the favourites are being used.
I want to know if 80% of my usage is coming from 20% of the code/features and I want to kill that 80% of resource sapping bloat.
The second spoiler resulted in a 200% increase in LOLz, good work.
I need two things :
a) WHO is using my feature/url and their behaviour as well as the total % of users visiting a url.
b) When adding a feature of any kind I need to how and when it will be judged, e.g. if after 4 weeks this search box makes no difference to the number of users going to a search page then kill it.
Too often I develop an application blind and I don’t want to anymore.
Of course what i’ve outlined is a problem, I need to create my solution. I’m building something to make sure that I have the right tracking to create a lean codebase (rubygem coming soon), and most importantly only having features make a real difference. I look forward to sharing it with you soon.