Miranj

Watch this space for our upcoming blog post!

Imagine for a second that this post had ended with just that one line. After making an effort to reach this blog, how would you have felt?

If I were to guess, it would’ve been one of the following:

• The post isn’t even out. Pointless!
• What a waste of a visit!
• Crap! Made a fool of myself by following a worthless link.
• Dickheads!

Now suppose this weren’t a mere blog post, but a really promising product that managed to catch your attention. You need want this product. You are excited about it and land on this page only to find out that it’ll be coming soon.

This time what could possibly be your reaction? Perhaps—

Can’t wait! When is this coming?

In both cases, the user undergoes a certain level of discomfort, anxiety and isn’t really happy about the situation. Yet the internet is littered with such heartless ​“coming soon” pages. In earlier days an ​“under-construction” sign (at times accompanied by a short animation) was put up when a website or a webpage was under development. The trends changed over the years and this was replaced by an optimistic, future-oriented and more promising ​“coming soon” sign. The plan is to generate excitement, build traction and finally a big bang on release day! The motive is undoubtedly good, but seldom do plans work out as expected. A more likely outcome is a frustrated user. We’ve been victims ourselves.

.@souvikdg on ​‘Coming Soon / Under Construction’ sites:
Dark alley, thug attack.
​“Help!”
Batman appears & says, ​“Just a sec coming soon.”

— Prateek रूंगटा (@rungta) October 4, 2011

Recently, one of our friends who was quite disturbed about the ​“coming soon” sections on his family business website confessed, ​“No one is working on it to bring it up soon!”. Very few stakeholders foresee these problems early enough, counting instead on their ​“clear plan”. Let’s analyse a couple of them:

We plan to build a product. Let’s quickly put up a coming soon page to keep people interested in our idea and then start building the product.

This move might serve as a promise and commitment to deliver, but it suffers from some fundamental flaws. First, the ​‘real’ work is pushed for later and instead a ​“coming soon” page is worked upon. Second, it is extremely hard to visualise the final product. In a software project, where change is a lot easier than in a traditional brick-and-mortar project, plans change very often (even while the product is being developed); the final product rarely matches the creator’s original vision. Chances are quite high that the ​“coming soon” page would have promised something different. Finally, there is an assumption that the project will ship and not turn into vapourware.

We plan to launch this application with Use Cases A, B & C. We’ll launch the website as soon as Use Case A is ready and Use Cases B & C can link to a coming soon page. While our Use Case A seeks traction we’ll work on the remaining features.

Again in this case, once a product goes live the focus from the pending features can easily be lost. User feedback, bugs and scalability are just a few things that might de-prioritise the work on Use Cases B & C. Trust us, refinements can take forever. Not to mention the possibility of a new use case being born. Ain’t it better to not pre-emptively market Use Cases B & C?

So, when to do a ​“coming soon” page?

For starters, certainly not before the product itself is ready. Once the product is built, nothing like taking the audience directly to the product instead of painting a rosy image in their minds and letting it rot by the time they get to the real product. Important to note, ​“soon” indicates an amount of time that is subjective. It is hard to tell by when the excitement completely dies out, or worse, turns into contempt.

However, in case one does wish to put up a teaser, setting the right expectations (both in terms of the product features/​offerings and the timelines) is important. Only once the product has been built can that be achieved. Build the product, set clear expectations and promise a date. Just how Apple does. Heck, even Virgle conveyed clear timelines!

Now come back soon for our next post. Just kidding!

The web is at its most powerful when used as a communication medium. Even as it evolves supporting richer formats every day, text remains the most basic and widely used format for expressing ourselves online. Ubiquitous almost. And given this ubiquity, it becomes pretty important for web designers to ensure that the message contained in those letters and words is conveyed as efficiently as possible. In fact, Oliver Reichenstein makes a compelling argument that 95% of web design is typography.

Typography is an important part of written communication, but not its sum total. There are other aspects like engagement and clarity that are just as important. This presentation thus begins by highlighting the process, setting the priorities right. It then goes on to some basic guidelines one can follow to improve the readability of the written word, and ends with a tease into some of the finer aspects of typography. The presentation concludes with two clips from Gary Hustwit’s excellent design trilogy that you can watch on YouTube: Michael Bierut on Helvetica and Deiter Rams on Good Design.

Like any worthy skill, grasping typography requires time and effort. Serious web designers would do well to invest both. This presentation though was made to serve as a starting point / basic introduction to the subject. Hope it helps!

Introducing projects to someone else who will bring your ideas to life can get really painful. We know, we’ve faced it ourselves.

Most respected web design shops have identified this problem and have attempted to solve it by using questionnaires with 15 to 20 questions as a starting point of introduction. A long questionnaire, almost as good as detailed documentation can be difficult to answer at such a nascent stage. Thoughts at this stage of a project are usually clear at the micro level, but most macro level details get clearer only as one progresses with the execution. Many a times one looks to seek advice rather than knowing it all. Steve Jobs nailed it when he said ​“It isn’t the consumers’ job to know what they want.” We concur. Such questionnaires are a step to simplify things, but we think that it could be made simpler.

Going by our Keep it Simple, Stupid principle, we have come up with just 4 questions. These are the most basic and natural questions you would encounter whenever you go out to buy anything, be it a table, a shirt or a computer.

Hi, how can I help you?
I want to buy a computer.

For whom?
My son, he’s 15. And sometimes my wife will use it, though she doesn’t know much about computers.

What will they use it for?
Well, simple things, maybe play some games and watch a few movies. And of course, browse the internet.

A customer should never be expected to specify how fast the processor should be or how much power the device should draw or even whether he needs a mouse (iPads for instance don’t have a mouse, but can still serve his purpose). If they know, that’s good, but we suggest consulting the experts before forming a mindset.

However, unlike buying things off-the-shelf, customised design and development jobs provide a huge room for flexibility. Hence it is very important to determine the size of the project. ​“I want my website to look like that” or ​“I want the website to have this feature” is a very small portion of the large pie. Micro level product definitions do not take into account the optionals like legacy browser support, responsive design, CMS integration etc. In many cases these variable components drastically affect the size of the project.

One way of defining size is by investing significant time and money documenting every little detail of your project. Unfortunately, making this list exhaustive is nearly impossible. Additionally, rarely does such a document go unaltered as a project progresses. No surprises that we prefer not taking this route. The other way of estimating size is by knowing the time and budget constraints. Well, everyone has a budget up their sleeves, but very few like to share it. While we understand their concerns for not being looted by a design shop, it is important to appreciate that the same goals may be achieved by drastically differently sized projects.

The 4 Questions

1. Your project in 140 characters (or less).
2. Who are your primary and secondary set of targeted audience?
3. What are your 3 most important expectations from the users who visit your project?
4. What are your time and budget constraints?

If clients share definitive and unambiguous answers to these 4 questions, everything else falls in place. That is why we have put soft constraints (140 chars, 3 expectations etc.) on every question. At this stage, we want only the essential ​‘user-centric’ goals of the project. Our designs are user-focused and these goals have our primary attention throughout. We know that only happy users translate into long-term happy clients. Nothing else matters.