I was pointed today to a new gmail feature called Mail Googles. The feature in discussion shows some mathematical calculations to be solved whenever you’re sending email late at night, in order to save you from ending those emails you did not want to send.
That is so wrong in so many ways.
First, the underlying idea is to save you from sending those emails you did not want to send (which according to them happen usually in the dead of night). I work at night and I send emails at night, mostly to clients. Usually I’m very tired finishing some deliverable or mock-up when I hit the new email button and start writing the blessed “here’s it” email, carefully remembering to attach the deliverables and press send… and now I have to fill some idiotic astronomy math tests whilst I just want to get done with this email and go to bed? Ludicrous.
And then, how many stupid emails do you send a day? A month? A year? Do we need to math quiz all the nightly emails in order to save us from that stupid “late night email to my ex-girlfriend” telling her “that we should get back together”? Yes, the answer is to annoy yourself to boredom every night until you don’t want to send emails anymore after 9:00 pm, thus avoiding telling your girlfriend you should hook up again.
Funnily, one of the cases they mention to support the new feature is sending a text message, which does not have anything to do with email. And both cases involve girls, thus making me think that guy has issues with the fair gender.
Perhaps Google got the idea that Microsoft’s patronizing model of we know better is the model to follow? Or is it just the Microsoft model of over-saturate products with smartass yet unuseful features? Or is it the Microsoft model of yet another productivity assistant that sucks production time out of you? I could continue ad nausea, but I’m sure you got the idea.
Why not instead show you a preview of the email? That way you can proof-read the email and decide to send it (like when printing). That way it gives you a minute of pause without the overhead of stupid math quizzes at 3:00am.
I can make an ass of myself, like any other person and I can tell you, most of the times, I’m drunk, not under-slept. Give me a mobile that blocks audio when the sensor in the microphone detects a high level of alcohol, or a T9 system that can count misspellings and ask you if you really want to send that many mistakes in a text (whether it being because you’re drunk or because you don’t know how to spell anymore, like many of the people I read on the internetz) and I’ll give you a million kudos for a great idea.
Give me a gmail account that asks me smart-arse math questions when I only want to go to bed and I’ll start reading gmail on Apple Mail.
Or, better: let people make mistakes, that’s how people learn.
UPDATE: xkcd shows us a better version of Mail Googles that really fulfills the purpose:
(Update: some people pointed out this is a feature you can opt-in to. I wrote this because Google opted me in, so for me it was an active feature. At 3am in the morning. Upon the delivering of a client’s email. So my thoughts stand).
Some days ago, I got a document from the company that I’m working for, stating a project’s technical guidelines for a client to be signed off. Most of the vocabulary was right, but sometimes wrongly used, as technological clichès. This mentioned document serves as a template for most projects, and I imagine that for a while it has not been revised in detail, as it seems to work, seems not to be broken.
It also happens with websites that features are not improved or redesigned because they seem to work fine. Even companies have the same approach, continuing to do things their way because it seems to work fine, it seems not to be broken.
And if it is not broken, why change it?
First, let’s think that perhaps what does not seem broken might be. We’re quite accustomed to see when something’s broken, but what if we cannot see it? Then we suppose it is OK. But there are new realms of broken that are not as obvious as cracks in the wall.
Same as with our health, perhaps a preemptive approach might help in those cases where, similarly, we take some doses of vitamin C to prevent a cold, as usually we cannot see we’re already infected, days before we can see we’re broken (ill).
Amongst the strategies we can follow, we could:
The one I use to approach my personal projects is the simplest and less rigorous, but has assured to me enough success and reliability: I assume that, after a certain time (that varies per issue) it has to be broken (or at least entering obsolescence). Many times it is, whether in language, content, semantics, usability, or just visually.
The web is a living entity, that evolves in time and every second has a new, different face. Being part of that world requires the amount of self-maintenance a living organ will need.
Check often, and you’ll see things will be less prone to break. Don’t wait until you revisit the site and get some broken image icons, or worse, the moment when your client tells you something is not expressed that way anymore. d’oh!
What is the value of an idea?
According to me, it is very close to none, null, zit, nada, cero, niente. And if you have had some, you know what I mean. We all have ideas. Some of us constantly. Some others every day. Some every some minutes. We have many ideas a day. Sometimes we don’t even notice.
These ideas usually take the form of solving a problem we have, or that someone else has. It starts to have a shape. It seems plausible. Then it seems possible. It might stay around for a while. Some of those ideas are rediscovered with time, some are immediate. Some haunt you, some are haunted by you.
Then it arrives: the time when it is solid enough for you to decide to keep it. You start thinking about it. You might (intelligently) start discussing it with others. If you don’t, it must probably die, unless it is one of those one-person idea. It seems smart enough. Damn, sometimes it seems amazing!
You start sensing a possible space for it. It might take some minutes, a day, a month, but you feel there’s a space, a market, a weight for it. You might even research if there’s a space for it. It itches. It feels like it’ll wake you up if you don’t pay attention to it. You think you have a ripe idea. What to do then? Keep it. It is your idea, after all.
This is what really happens:
Our mind is a complex, intriguing, wonderful thing. And it is our best friend, believe it or not. Why? Because it cares so much about us, it even bends reality to prove us right. Back at architectural school, the first thing everyone of us used to discover is that once you have a spatial idea for a building, it seems that suddenly it all makes sense (in your mind): corridors, services, spaces, structure. It all found and had its place in the complex system of connections. It seemed plausible. Then you started sketching, planning and drawing, and you discovered that those corridors did not make sense, that space for services was not there, and if it was, sometimes they were better somewhere else. That the structural array was impossible in that configuration of spaces. That entrances, aisles and doors were better some other way. That spaces did not completely satisfy the brief. So you started the second and most important part of designing: the design process itself.
If ideas had an intrinsic value, design will not be that important a process. It is in the detailed drawings and models, in the relational sketches, in the sections and even in the material selection where an idea starts making sense, having a life of its own. Being something more than an idea. Becoming a product.
After a couple of weeks perhaps, you (luckily) had a possible project in your hands, usually so different to your idea that you could but barely recognise it in the ink drawings and the cardboard scaled walls and ceilings.
Ideas are like seeds, small and concentrated amounts of energy that need to grow into trees. But as ideas, seeds need to develop, need the effort and the energy to grow, need water and sun and soil. Need, most of all, time to evolve.
All healthy seeds might represent a future tree. One seed is not worth a tree, but with the necessary amount of time and support, it might become one. It is, however, the tree that has all the value.
Take your ideas as seeds, select the ones you want to grow, and make them into wonderful trees. And if you feel like not growing it, share it for someone else to grow it, as their value is in becoming trees.
Just don’t sit on those seeds. Unsurprisingly, they won’t hatch by themselves.
Service design seems to (still) be one of those things everybody wants and is doing. It has arrived from and to conferences, it is asked and sold to clients to diversify and enhance their brands while keeping the customers and users satisfied. So it might be time for everybody to think what Service design is. Perhaps a definition might be difficult to grasp, let alone to utter, and I might not be at the level to summarise it in a sentence, so I’ll try with an example, and as such I’d like to compare it to a product, its eternal nemesis.
A car is a product. Some car company designs it, engineers it, produces it and sells it to you. You now have one way to go from point A to point B and back, and even listen to the radio news while waiting in point C for that traffic jam to clear. When you buy the car, you’re buying transport, a means to an end, the freedom of being able to go anywhere whenever you want to. You’re also buying tyres that wore out, an engine that might break, a gear system that you have to switch in order to advance, windshield that might break, wipers that stop wiping, gas tank to be filled every now and then, and so on. Later, once you own the car, you’ll realise you need insurance, and if you crash into that fat guy while checking out that blonde, you also buy a device that might spend days in the car shop, while being disemboweled and reconstructed and then it might work again. You might find yourself in the middle of a highway while it rains cats and dogs, you might be robbed of your precious vehicle, you might lose it to a lucky double deuce on a frantic poker night.
So when you buy a car you buy a solution to a necessity (to go from A to B) together with a myriad of other problems (how to keep the solution from dying on you).
Cabs are a service. If you need to go from A to B, you raise your arm, hail one of those yellow/black/white automobiles, open the door, utter where B is, and sit back and enjoy the ride, or suffer it. You get to B, get down, pay the fare and run upstairs to your next life event. When you hail a black cabby, or a yellow cab, or a white taxi, you’re buying the ride. Which might be the same reason you’d buy a car, but this time without the blonde and the crash, no worries about missing the insurance renewal deadline and careless if your tyres are worn out.
So a service is that series of processes and events that allow you to get (and pay) for exactly and only the one thing you really need, and get it, no more and no less.
Most of us when talking about a service we imply what is called the touchpoints of such service: the teller on a bank, the credit card paypoint, the salesperson on a store, the McDonalds unresponsive teenager, the idiotic ever-broken cash machine, the screen of your cellphone or even the cellphone itself. A normal thought if we realise touchpoints are the service’s faces we deal with.
Essentially the service is all that makes your money be there when you need it, the burger to arrive to your mouth when you are hungry and the conversation with someone, countries away, to happen. Since a service is a very complex system of events most of which are invisible to us, I’ll divide it structurally into front-end (touchpoints) and back-end (framework).
Most companies have endorsed and advocated for their provided services by creating “better experiences for the user” and a million other marketable phrases of the same genre. Those companies have improved much, and we might even be glad of it, very glad indeed; but their reach might be that of just the touchpoints. Airline counter crew smiling more than Ronald McDonald, call centres where they seem to be so high a hysterical laugh might escape any minute, promises of “better support”, “seamless communication” and “improved interface”, salespeople that simply love to make a deal with you while making you feel “the master of your domain”. And a month after you find yourself on the other end of an hour-long call centre chat that suddenly drops down, or having at home seven versions of the same modem, all of which don’t work exactly in the same way; and you wonder where the bloody hell is that service they promised you.
The answer is nowhere. That service was never there. Touchpoints, all of them, were elegant, serviceable, happy as teletubbies and polite as grannies, but completely unsupported by a real service backbone, the framework that makes the modem arrive to your home and work, or the system that makes your call convert into the satisfaction of getting what you’re paying for.
Service design is about making things go from A to B, not to paint in rainbow colours touchpoint A so you buy it and then figure out where on earth is B and how to get to it while holding your tears or saving your bullets. Don’t get me wrong, it is also about making point A and point B as satisfactory as it’s needed for you to want to traverse them, but that need/initiative seems already embedded in the culture of currently successful service design enough not to make me worry that much. However, we might touch it in a coming post.
As an example of how services might be perceived and delivered, I’ll mention FedEx ((I am in no way advocating for FedEx as an example of good service, only using it as an example of a promise and a fulfill, relation that is the cornerstone of any service.)). The worldwide known courier post company FedEx don’t promise a nice box delivered to your home/office, it promises a nice box whenever you need it to be whenever you need it to be, “absolutely, positively overnight”. And that’s what you’re buying. That is the service. A nice anecdote on how that service was born is given by Business Journalist Roy Rowan in his book “The Intuitive Manager”:
He cites the birth of Federal Express, the company that created the market for overnight mail delivery. The idea for the business first came to Founder Frederick Smith while he was a student at Yale writing a term paper on the parcel-service system. Much later, while he was flying combat missions in Viet Nam, Smith developed his notion of an “absolutely, positively overnight” service.
— Hailing the Eureka Factor
I don’t really know if that anecdote is true, but it does not need to be for the idea of FeDex service to live, as many of their ad campaigns have stated it over and over, and it has become the promise, the need to be fulfilled. If a FedEx nice-boxed package does not arrive when they told you it will to arrive, the service is broken, and you might not feel a satisfied customer, period.
In this era of so much discontent with pollution, consumism and sustainability, services are one way (the only, perhaps) to attain the most of those, so we might as well get our heads straight and our goals fair and aim for getting our users from point A to point B, “absolutely, positively overnight”. Not just giving them better experiences.
Continue the reading:
While reading this post on Looks Good Works Well by Bill Scott, I started wandering about scale and methodologies. As Scott mentions, when he started using Extreme Programming in agile methodology, it worked for him when not taking it literally or dogmatically, but as guidelines that informed his process.
I wonder if that is not a result of scaling (up or down) the method to the process.
As I see Jason’s approach to work, it more and more seems like ideas that have arised from his own experience at 37signals, and thus are informed by many a characteristic of his own enterprise, such as scale, dynamics and communication methods. An excerpt of Jason’s key points from the article:
(note: this does not pretend at all to be a questioning or judging on Jason’s arguments, it is just a personal reasoning started by these points)
Keep your team small
– Forces you to focus on what’s important
– Clearer communication comes for free
– “Communication usually fails except by accident”
Collaboration is about communication, not control
– Keep your team apart. Interruption is not collaboration. Interruption is the enemy of productivity.
– Encourage alone time
– Stay away from each other as much as possible
– Communicate more passively, less actively.
Meetings are toxic
– Usually a symptom of a problem, not a solution. Mentioned a business leader in Brazil who advocates that all meetings are optional.
– Meetings convey an abysmally small amount of information per minute
– Require thorough preparation that people rarely do
– Tend to procreate
Instead make tiny decisions
– Decisions are progress
– Progress is great for morale
Most of these points are sound and seem to tackle rather well some inner problems of company productivity. Yes, meetings consume valuable time in a rather unefficient way, and yes, uninterrupted time might prove as a very productivity-savvy tool, and yes, keeping your team small helps having an eye on mostly everything.
But (and this usually tends to be a big but) what if you’re handling the intranet design for such a multinational behemot as Dresdner Kleinworth or Accenture? How small your teams can be? How many conferences and meetings you might avoid before the team is completely uninformed? How many uninterrupted time you can have before you fall out of the client’s loop?
My way of seeing it, and where de weakness is, is that all that smart and sound advice is directed and intended for a rather small audience: that of start-ups, small companies, design studios; but it is not explicit in its wording.
Small is not necessarily better: Apple is great and big. Small teams can take care of some projects like Backpackit.com, but not British Gas’ many service websites.Tiny decisions help keep things being done instead of being talked about (as it happens in meeting-driven and design-by-comittee cultures), but in a big project scope can be missed.
I am in no way saying I am contrary to these guides; I am convinced they work, and I believe in most of them as great guidelines to improve your workflow, project and product/service. I just miss the appropiated context on where to apply them, or better, from where to rethink and adapt them to the existing context.
There’s a great book S, M, L, XL by architect Rem Koolhaas. It defines a common ground from where to think about scale inside architecture. His approach is that every scale has its own advantages and shortcomings, and we have to focus on them to exploit them at their maximum. After all, it seems rather unlikely to pretend that you can build the Pyramid of Giza over Agile Architecture. But that thought might be completely wrong.
That’s one thing I might start thinking and working towards, as little has been said on how big companies can benefit from these forward-thinking productiveness-driven guides.