A few years ago, we got a checklist of proposed features from a client. They wanted the site “.mobi enabled”. We spent a few minutes looking at each other like dogs trying to understand calculus, and then realized, fundamentally, that we were looking at a “someone read a white paper” scenario. They wanted to get in on the big buzzword, but had yet to analyze the value proposition.
Nobody’s going to discount the growth of mobile. We’ve all got our collections of phones, tablets, and even the occasional netbook. However, a fortune thrown at mobile development will net you no extra revenue if it doesn’t serve a user purpose.
When we bring in an existing website, it’s often like bringing in new government to take over after a coup. There’s both fear and hope in the hearts of our clients. But most interestingly, there’s a lot of similarity in the aftermath you have to build from. By being able to pick the right metaphor for the site, you can know what’s likely to happen when you get developers in to fix it.
We often have customers coming into us asking for a shopping cart. Admittedly, this is often a complex process. There are few brand names the average consumer will recognize. Many times, a list of 300 features consists of ten you care about, 30 which you assumed were in every cart, and 260 which are only of use if you do drop-shipping to customers in Outer Mongolia and accepting payments in Vanuatuan Vatu. Now, we don’t expect you to come to us saying “CS-Cart please”, or “We want Zen-Cart”. We’ll do the research, but you have to meet us halfway– there’s a lot you can plan in advance to make the process easier and much smarter.
I know you want the entire site to roll out on launch day. The huge cart with 5,000 products. A blog with articles stretching back to when Al Gore first breathed life into the Internet. A customer-relationship management package so sophisticated it has seperate responses for every obscenity an angry customer uses with your call centre staff. But is this the best choice for your company? Probably not.
A staged deployment offers you several benefits at no significant extra costs.
In this blog, I tend to be inspired frequently by the interactions I have with clients. Over time, you see the same requests again and again.
A real doozy is the “can’t we edit…?” line of discussion. Whenever you build a database-driven system, like a CRM system, or even a sophisticated order-tracking or shopping cart system, people decide they want to be able to edit the enterred data.
Now, there’s nothing inherently wrong with allowing you to edit PARTS of your data. The trick is to abstract it– rather than editing data with no constraints, you provide the functions to perform legitimate business operations. For example, it makes sense to have an “update customer address” tool, or a “delete product from order and adjust price tool.” The dangerous aspect comes when you want to start editing any field on a record free-form.