When a customer asks for a new feature, it’s quite often something that makes perfect sense.
My heart says “Sure thing, we can do this pretty quick, let’s go for it”, while my head says “There are no small changes“.
Ryan Singer wrote about icebergs & code cakes recently. I nearly broke my neck nodding in agreement.
Let’s talk about icebergs…
We call them icebergs because what can be seen is trivial in comparison with what goes on beneath the surface. They can harm projects in 3 different ways.
A UX designer adds it in, not understanding the complexity.
A client is furious when an agency won’t bow to a seemingly tiny UI change.
Users of an app grow frustrated when a seemingly small change seems to take forever.
Iceberg: Search
Search is a great example of an iceberg. The user see’s a text field and a button, followed by a results page. The user doesn’t see the development nightmare. Here’s what has to be decided and coded:
What are we searching across? Projects, messages, comments, to-dos? What about people? Should people be searchable? The TSA thinks so.
What about files, should we search inside them or just the filename itself. Or both?
Should we segment the results, or put them all together. Do the results need to be filterable?
Does this have to be real-time or can we pre-index?
Unless you’re familiar with these issues, it’s difficult to see a text input with a magnifying glass as taking weeks as opposed to hours. If you’d like further details on what goes into Search – read this piece by Garrett Dimon about search inside Sifter.
Suggestion: If search is a commonly requested feature in a web app, it’s usually a sign that something else is wrong. In Intercom we’re occasionally asked for search, but after discussion it always translates to “Get to a particular user quickly“. This is far easier to design and implement than an application wide search which both looks and sounds similar.
Iceberg: Rich Text Editing
To avoid the issues caused by taking on all HTML elements, colors, backgrounds and styles, Basecamp offers only bold and italics and lists. The poor man’s rich text. However, even with such limitations, rich text causes problems, as can be seen in the above image. They’re just not immediately obvious in the interface.
To the end-user rich text editing seems like a trivial addition, a “must have” maybe, but for development and maintenance it can be a nightmare. There are heaps of solutions out there all which claim to easy to integrate, but it’s rarely that easy, and the HTML produced usually is well below par. It’s one thing playing with colours & fonts in a text area, but maintaining the formatting as it moves around the app, page to page, from app to email, to mobile, to SMS even, it’s an iceberg.
Suggestion: Use rich text only when it’s a necessity. It’s interesting to look at how many apps regular folk use on a daily basis that don’t support it (for example Facebook, Twitter etc), and how much better off they are because of this. If you absolutely need it, plan for what happens in all the different places the content will displayed (app/email/iPhone app/SMS/etc).
Iceberg: Email Processing
Email notifications are common in web applications. A new comment has been posted, a new event has happened, someone replied to something. You can invent the worlds most amazing communication tool, but you’ll still end up falling back to emails to let people know what’s happening. Ask the Google Wave, Buzz Plus team.
Now here’s a two-part iceberg…
Users read these emails
Users reply to these emails
The first point is a problem as you don’t want to re-notify users when they arrive in your app about something they’ve already read. You see this happen in many apps. Facebook doesn’t know that I’ve read their emails, so they still show me updates in the app too. Basecamp uses icons to differentiate what you’ve read and what you haven’t, but that doesn’t realise that I read most Basecamp messages in GMail.
So the thing to do here is attempt to detect when an email has been opened here, but that brings with it a whole wave of problems, and is itself another iceberg. A significant development effort to ensure that users don’t see something. Good luck trying to promote that on your marketing page.
The second problem, people replying to mails, also needs to be addressed. The zero point “solution” is to begin each mail with “DO NOT REPLY TO THIS MAIL” and have it sent by do_not_reply@yourWebApp.com. That’s a bad experience for your users. So if you are intend on delivering a good experience, you’re now in the world of parsing inbound email, grouping it with its context, handling HTML signatures, and all that fun stuff.
Suggestion: Some icebergs are too big to sail around. The best you can do is plan for all cases for all emails and use the best tools available for email processing. If you know you’re opening a can of worms, best put some gloves on first.
Show me yours
My favourite iceberg was on a project where the addition of one button labelled “Merge accounts” resulted in 6 weeks of development work and then got scrapped. What icebergs have you encountered in designing or building web-apps? Let us know in the comments.
Photo credit: Rita Willaert
Comments