One of the most interesting aspects of Agile development is to not build things that you won't use now or over-engineer a component because "we might need this in the future". That is a wonderful thing for developers and it does cut a lot of complexity and time to deliver the feature, by consequence making it less buggy.
But what about the business/marketing sides of things?
I've been thinking a lot in a new way of building features and I'm giving it the name "organic feature". This is not something we've been practicing at Sampa frequently, but I'm starting to think we should.
Organic Features have two important aspects to it:
You write down or sketch the minimum set of functionality a feature must have to add any value.
You implement the minimum set before you start thinking about the additional elements.
Organic Features have two big DONTs:
You don't start by thinking of all the corner cases and how you can address all of those.
You don't overspend time creating a UI mockup without having implemented the minimum set first
Now, you don't ship the feature after you implemented the minimum set. That's the bar to make sure the core functionality is working, but it still doesn't mean it addresses basic scenarios of your customer. Here comes the "organic" part: You start adding to that base of features after getting the initial feedback from internal people on what they think. The goal is to add a little bit every day and at one point you have the feeling the feature is done and ready for customers.
After you ship the feature, you'll still need a few more iterations to fix core scenarios that were missed, to fix assumptions the team made about the UX or terminology that is getting users confused, and, of course, to fix bugs.
I'm my opinion, Organic Features are the opposite of "Spec'd Features". Spec'd features are built from the inside out, usually one or more person thinks through what it should do, what customers want, what the UI limitations are and they try to be as comprehensive as possible, since the deliverable of this work is a complete "spec".
The core issue here is that a "spec" might write one line that converts into thousands of lines of complex code, or have a three pages to describe something that will take just a dozen or so lines of code. Using the organic feature strategy, it makes it easy for all the people involved to understand the cost/benefit of building the functionality, and as the feature gets closer to complete, more initial complex ideas may become trivial to add or integrate.
This is just a first essay on this topic and I still have a lot to think about this, but think of Organic Feature building as a way to get rid of specs and prototyping.
If you look back at the Sampa sign up form, it has been through 4 or 5 different versions. At one point we asked you about 15 questions. Then we worked with one local UX expert to simplify a bit, then we worked with a Portland-based UX firm to simplify it even more and we had just 8 inputs:
Name
Email
Confirmation of email
Password
Confirmation of password
Agree to Terms of use
Web address
CAPTCHA
After reading the book "Web Form Design Fillin in the Blanks" (by Luke Wroblewski) over the 4th of July, I decided to take a closer look at our sign up form again.
I am always afraid of making any change to our sign up pipeline since we have such fantastic conversion rates that is easy to assume something, make a change and it to backfire.
Well, there was at least one change I've made that was a no-brainer. The Terms of Use checkbox wasn't checked by default and I changed that.
But that's not the interesting part. On the book, Luke mentions that a lot of the things we ask on forms are limitations of the application itself and that it doesn't add value to the customer ("inside out").
You can clearly see some of that on Sampa. Why do we ask twice for your email? Why do we ask twice for your password? Why do we need your name? Why do we need CAPTCHA?
We have good answers for all of the above, and we A/B tested several scenarios over the last 2 years to know that we are close to the right combination that yields maximum conversion and retention. But one piece was never tested and it was off: CAPTCHA.
Why do we need CAPTCHA? Like any other free web service that you sign up to (Hotmail, GMail, Ticket Master, Blogger, etc.) CAPTCHA is necessary to prevent automated bots from creating hundreds or thousands of fake accounts, either for Spam or Link Farm. So it's a necessary evil that good people have to go through so we can keep the bad people out, or is it?
Well, last Monday at 5:13 PM we removed CAPTCHA from Sampa. It wasn't easy and clean, but we created a set of tests and rules that will make us not display a CAPTCHA about 99% of the time. I can't really disclose the tests we make since that's the secret you want to keep out of the hands of bot creators.
The result: 9.2% improvement on our conversion rate!
The entire team is just shocked that such a huge percentage of users wanted to sign up to Sampa and either didn't pass the CAPTCHA (less likely) or found the form more intimidating with a CAPTCHA (more likely). The third explanation which we've been talking about is that with less vertical space, the "Continue" button is above the fold more often and give users a better sense of how short this form is.
When I started Sampa, I thought that most content would be traditional page GET/POST. But then I went back and checked a family tree that I did for my personal site in 2000 that used AJAX. It made sense to use that technology on Sampa and I went overboard. I created my own AJAX framework (in 2005 there wasn't anything solid that I could use) and used AJAX everywhere on the system.
Later AJAX started to become a pain, because a page after being loaded required 3 or 4 AJAX calls to get the additional content. Bad design for the user. The good part is that Sampa used a combination of Frames that allowed us to cache content on the browser, so the AJAX calls to the server were minimized.
From a development standpoint, AJAX is a pain because it requires you to parse the returning XML and do something with it, usually generate some HTML or data structure. This is where AJAH and JSON come in hand.
If you need a piece of HTML to sitck on the middle of the page, you can generate that HTML on the server and send it on an AJAH call. Once you get that is just a matter of setting the innerHTML on an element.
JSON does the same thing, but for data structures and its data in Javascript. Get a JSON response, eval-it, and you have data and 'classes' ready for use, instead of parsing the XML and putting into a data structure.
So, of the 4 technologies above (in-page, AJAX, AJAH, JSON) which one should you be using on your web-based service? All of them! Each one solves a different problem and they need to be used in combination.
This is my non-comprehensive list of tips on those technologies:
in-page: Use that to minimize server calls when the page is first loaded. The same way you should have few CSS, JS and Images file on a page, you should try not to make any JSON, AJAX or AJAH call once the page is loaded at the first time. Everything should be embedded on the HTML you send to the user.
AJAX: Great to take action on the server ("delete this record") without needing to refresh the page, or when you need pagination ("contacts 1-50 of 1750").
AJAH: When the HTML generated is smaller (or faster) than sending an AJAX response and creating the HTML in Javascript. It's also good because you can keep all the HTML generation routines on the server. Like AJAX, you should only use it when you can't have the content embeded on the page directly on the first page request to the server.
JSON: When the results of an AJAX call will be parsed into a data structure, you probably should consider JSON. Size of the response and parsing time are important considerations. Remember "eval" can be very very very very (add 17 more 'very') expensive at runtime. You don't want your user's browser freezing every time it clicks on something.
I'm a big advocate of using 1 or 2 letters field names. Instead of "Username" just use "n", and that goes both to JSON and AJAX. Put the comment on the code to what it means, but save a lot on response size.
It has been just a few days, but Dave Sampson is already making his mark on Sampa as VP of Marketing. Dave is a convert. He started as a techie and moved into marketing, which is just the kind of person we were looking for.
The VP of Marketing at Sampa was the position that was open the longest, probably since I started Sampa in 2005.
You can read more about him on our Leadership page, on LinkedIn or watch one of his lecturers at the University of Washington where he teaches Marketing on the Software Product Management Certificate program.
Subscribe to this Site
page, on 
September, 2007