Menu

Links and articles about technology, design, and sociology. Written by Rian van der Merwe.

[Sponsor] Mandrill: the fastest way to deliver email

Thank you to Mandrill for sponsoring Elezea this week! I’m a big MailChimp fan, and this is another great product of theirs.

Integrate, deliver, track, and analyze with email infrastructure from Mandrill.

Mandrill is a scalable, reliable, and secure email infrastructure service trusted by more than 300,000 customers. It’s easy to set up and integrate with existing apps. And it’s really fast, too. With servers all over the world, Mandrill can deliver your email in milliseconds. Detailed delivery reports, advanced analytics, and a friendly interface mean your entire team—from developers to marketers—can easily monitor and evaluate email performance.

Get started with Mandrill today.

Mandrill

Sponsored via Syndicate Ads

Content outlines as part of the prototyping process

Sophie Shepherd introduces some new deliverables in Rethinking Our Prototypical Process, including this one:

HTML prototypes have the potential to confuse some clients. In addressing feedback, I’ve answered questions like: Are we tied to this layout? (No.) Is this real content? (Ideally.) Is this what our website will look like? (Probably not.) The content outline strips any potentially distracting elements from the prototype: no layout, no typography, no links, no things remotely resembling design. It’s just a list of the content that will be on each page in order of its importance.

This deliverable, which she calls a “Content outline” or “Page description diagram”, seems like it fits well with my idea of Content slice diagrams. It’s great to see these new useful deliverables emerging — a sensible retreat from the “get out of the deliverables business” march of the past few years.

Single-purpose products

Craig Mod discusses single-purpose products in his product design essay There is much to learn from the paper towel:

All of these single-purpose tools or philosophies strive towards the same goal: whittle away the cruft around an idea to reveal its most base components, and in doing so, strengthen what is left.

The single-purpose lecture attendee is, in theory, a better student. The single-purpose-sized paper towel makes us happier, is gentler on the earth. Individual tools in unix are more efficient and easier to debug because of their specificity. Facebook Messenger on its own is easier to use to communicate without the deluge of Facebook notifications flying in our faces. And so on and so forth.

I’ve started using Craig’s solution for single-purpose Twitter notifications and single-purpose Facebook messages and it works really well.

Makers vs. Users

I really like Alex Maughan’s post In a word, Human. He discusses the dangerous gap between those who make software, and those who use it:

Successful user experiences happen when producer whims get sidelined, and primary focus is placed on that little bit of common sense shared by the majority of humans using your product or service. It’s when you empathetically put yourself in the most common psychological flow of a human using a piece of technology they know almost nothing about.

This is a topic I’m very passionate about, so I agree wholeheartedly with Alex.

[Sponsor] Readymag: Web Publishing Tool for Creative People

Usually we use a bunch of different software for creating such things as websites, presentations, photo stories and online magazines. The truth is — it all can be done easier and with one tool.

Do design, forget about coding.

Readymag provides a simple online tool for designing and publishing all forms of content, helping to focus on the creative process, rather than interface complexity and code. Among the main Readymag’s features:

  • Viewport: Easily create responsive layouts for mobile deviсes.
  • 1500+ free web fonts: From Typekit, Webtype and Google Fonts.
  • Password protection: Create private publications and share with specific audience.
  • PDF-export: Save and view your work offline.
  • Ready-to-use templates: Made by talented designers from around the world.
  • Plus: Free hosting, custom domain and analytics.

Stay creative. Try Readymag now for free.

Readymag

Sponsored via Syndicate Ads

Don’t be a manager like Dora

Just as my 5-year old exits her Dora the Explorer phase (to replace it with “Let it go! Let it gooooo!”), my 2-year old enters hers with the force of a thousand purple monkeys. So, look, I read a lot of Dora books these days. Recently Penny the Pony’s Big Race has been quite the hit. It’s about Dora trying to get her horse to… wait, who am I kidding. I’m sure you care about the plot as much as I do.

Anyway, there’s one part of the story that irritates me way above my average annoyance levels with these books (which is already quite high). Dora, Boots, and Penny are trying to cross a mud pit, but Penny is a bit scared. This is where we pick up the narrative:

Dora ugh

Let’s reflect on this for a moment. Penny is scared of jumping across the logs, because she thinks she might slip and fall into the mud. Dora’s proposed solution is infuriating:

Uh-oh! Penny is afraid that the logs might be slippery. Let’s count the logs as she walks across so she won’t be worried.

How is that a good solution? There are a number of things you could do to solve Penny’s fear of the slippery logs. They could walk around the mud pit. They could make sure the logs are more secure. They could give Penny special horse-shoes that increase friction. Look, I don’t know, I’m not an expert at horses jumping over logs, but I’m sure there are people who are, and who could come up with a good solution for the problem. Counting the logs to distract Penny is a pretty superficial and condescending approach to address this particular problem.

The thing is, this is all too often how managers operate in the context of their teams. Oh, you’re unhappy with the culture of the company? Let’s throw a company BBQ. On a Sunday afternoon. You’re concerned that the product development process is not optimal? Let’s hire another development manager. Instead of spending time to understand the cause of the anxiety communicated by team members, managers often rely on distraction or easy answers that give the illusion of a solution, but is nothing more than a way to check a box to say that they “did something.”

I read two really good management articles recently that are relevant here. The first is Gregg Satell’s What To Do While You’re Waiting For Steve Jobs (beware, that’s a Forbes link, so you’re going to have to do a lot of clicking around to dismiss all the things that try to distract you from reading it). He says this about treating people with respect:

If you expect your employees to be motivated to do their jobs well, you’d better treat them with dignity. Leadership is not the art of getting people to do what you want, but inspiring them to want what you want.[…] While many leaders believe that they can bend the organization to their will, that’s rarely true.  Being a jerk doesn’t make you Steve Jobs, it just makes you a jerk.

The second is Lindsay Holmwood’s It’s not a promotion — it’s a career change. It’s a great post and you should read the whole thing, but I want to quote most of the opening in full, because it’s great:

Your job is not to be an engineer. Your job is not to be a manager. Your job is to be a multiplier.

You exist to remove roadblocks and eliminate interruptions for the people you work with. You exist to listen to people (not just hear them!), to build relationships and trust, to deliver bad news, to resolve conflict in a just way.

You exist to think about the bigger picture, ask provoking and sometimes difficult questions, and relate the big picture back to something meaningful, tangible, and actionable to the team.

You exist to advocate for the team, to promote the group and individual achievements, to gaze into unconstructive criticism and see underlying motivations, and sometimes even give up control and make sacrifices you are uncomfortable or disagree with.

You exist to make systemic improvements with the help of the people you work with.

If I could summarize the advice in these articles, and what I’ve personally experienced about good managers vs. bad managers, I’d say this. If someone on your team complains that they’re worried about slippery logs across a mud pit, don’t tell them you’ll count loudly as they jump to distract them from the fear. Instead, take the time to understand the cause of their fear, and help them solve the real problem behind that fear.

In other words, don’t be like Dora. She’s a terrible manager.

Content First design with Content Slice Diagrams

A while ago I wrote about expanded customer journey maps as a way to plan for device-agnostic design. But that document is only half the story. Expanded customer journey maps are great because they force us to plan what content will be needed before we move to page layout. That provides a great starting point, but crossing the chasm between knowing what content should go on a page, and how to design the best layout for that content can still be quite difficult.

What we need is an effective way to make content hierarchy decisions across all pages so as not to lose sight of the overall consistency of a site. Enter Content Slice Diagrams as a way to accomplish three fundamental tasks:

  • Get an overview of the content across a site to make sure nothing is missing and there is consistency in layout where appropriate.
  • Design the right size and hierarchy of each of the content chunks on a page, and see how it affects the page as a whole, as well as related pages.
  • Provide any guidelines that writers may need to keep in mind as they create the content for the site.

Once the content slice diagrams are completed, designers and writers should have the following information:

  • A clear understanding of the hierarchy of each page, which leads seamlessly into mobile first layout design.
  • What the structure and nature of the content in each chunk will be.

That’s everything you need to start working on layout. As an example, let’s say you’ve worked on the content plan (see my post on expanded customer journey maps for an example), so you know what type of content needs to be on a page — but you’re not sure how to lay it out. A Content Slice Diagram can help:

Content Slices

What we have in the image above is a list of pages that goes from left to right, with rectangles representing content chunks on the page. Calls to action and optional modules are given a different color so that they’re easy to differentiate. When we did this for a travel site we realized that we sometimes had the call to action in a different spot, so we were able to get consistency across pages. We also moved the content chunks around until we arrived at a hierarchy that made sense.

You’ll notice that this looks suspiciously like the layout for a mobile screen… That wasn’t the original intent, but it ends up being a welcome side effect of doing content slice diagrams: it’s a great blueprint for mobile first design.

Once the hierarchy is set, you can create content guides for writers to give them the structural information they need to start writing:

Content Slices

When I brought this technique to HealthSparq, my colleague Allan White had a great idea. He rightfully commented that OmniGraffle doesn’t make it particularly easy to drag content chunks around quickly. So he decided to use Trello instead. It allowed him to have collaborative meetings with the Marketing and Development teams as they discussed the hierarchy of each chunk:

Content Slices in Trello

As I’ve mentioned before, I hate needless deliverables as much as the next person, but I really like deliverables that help us design better products. And I think Content Slice Diagrams make for a great addition to the tools we have at our disposal to design device-agnostic, content-first experiences. Use at will, make it better, and let me know how it goes!

Software is sometimes done

In the midst of the recent brouhaha about Markdown1, Craig Mod posted an interesting tweet about the nature of software. In response to John Gruber’s assertion that the original version of Markdown doesn’t need a significant amount of work, he said this:

This gave me pause, because it flies in the face of a very common mantra in the design world. Sure enough, it didn’t take long for another big name in Design to throw down the words many of us have said over and over:

This happened a while ago, but I can’t stop thinking about it. Craig is one of my favorite thinker-writers (hey, if singer-songwriter is a real word, this is totally a real word as well), so I didn’t want to treat it as just another easily-refuted throwaway comment.

The fact is that it isn’t that long ago that software was actually done when it came out. It’s only a couple of decades ago that software showed up on a CD-ROM and we made videos about how to use it:

Windows 95 video

When Windows 95 came out, it was done. Yes, there were some patches to it, but they were few and far between, and in general quite difficult to come by. But of course, then the Internet and App Stores happened in full force, and suddenly we decided that “Software is never done”. In some sense this is certainly true. There are always bugs to fix, things to improve, more features to add, unused features to remove — and of course, the SaaS model makes it all so easy. But I wonder if we’ve taken this a bit too far.

A fairly recent example that comes to mind is email software Sparrow’s acquisition by Google. Man, did we freak out about that one. The thing is though, the software didn’t suddenly stop working just because it was “done.” It was still there, it was still great, and it still works to this day. But that’s not good enough for us any more. Things have to keep getting better and better. And that’s fine — I’m not arguing against progress. In fact, I deliberately turn off automatic app updates on my phone because I love updates and release notes so much.

But I also wonder if our obsession with the never-doneness of software — the inherent throw-awayness of our MVP and test-and-learn culture — is having a negative effect on the quality and lasting meaning of the software we make. I’m reminded of Jennifer Fraser’s words in her article What I Bring to UX From … Architecture:

As an architect, the implicit permanence of designing a building carries with it a sense of responsibility… I can’t help but wonder if we would have better designed products if some of that responsibility and sense of permanence of architecture found its way into what we do as user experience designers.

And here’s Tony Fadell, talking about the creation of the Nest thermostat:

Fadell looks out at the Manhattan skyline and says that he always wanted to be an architect; that buildings stay beautiful forever but digital devices are quickly obsolete. “You look at hardware or software five years later? They’re crap. You would never use them again. People use architecture all the time.”

His voice rises. “What is our form of architecture? What is the thing that lasts of beauty?”

Or consider Dmitri Fadeyev’s words in a discussion about Russian architecture:

What’s interesting about this type of architecture is that its aim goes far beyond that of creating a functional underground system. Its aim is to promote a political ideal, and it does it through beauty by enriching lives of the people who get to experience it. The question here isn’t: how do we solve the problem of creating a metro station in an efficient manner – instead the question is: how do we create a station that elevates people’s mood and inspires their lives. This architecture isn’t there just to help you live – it makes life worth living.

I do wonder what would happen if we felt the weight of responsibility a little more when we’re designing software. What if we go into a project as if the design we come up with might not only be done at some point, but might be around for 100 years or more? Would we make it fit into the web environment better, give it a timeless aesthetic, and spend more time considering the consequences of our design decisions?

Coming back to Craig Mod’s tweet, I have to say that on reflection I agree with him. We need more software that’s done — not all of it, just more of it. Just like we’re always going to have prefab buildings to serve a particular function at a particular time, software that continues to change and improve pushes us forward and is absolutely necessary. But maybe it’s ok for Markdown to be done. Or Sparrow. Or that app you’re working on. And by going into it with a realization that this is going to be done some day, you might even make something that lasts for decades.


  1. The details of the Markdown argument between John Gruber and Jeff Atwood isn’t the point of this article, so don’t worry if you missed it. 

Coffee and Craft

Coffee and Craft

This essay originally appeared in the 8/1/2014 issue of The Loop magazine. It’s a publication worth paying for, and it’s run by Jim Dalrymple, a gentleman with a fantastic beard and an even better laugh. Thank you, sir, for giving me an opportunity to write for The Loop!

1.

My favorite story about coffee is from the year 1600, when Pope Clement VIII was the head of the Catholic Church. As the story goes, the Pope’s advisers urged him to make coffee a forbidden drink for Christians. They argued that since Muslims were not allowed to drink wine, Satan invented this “hellish black brew” as a substitute. In a moment of remarkable foresight the Pope asked to try a cup before he made his decision. He was so enamored with the concoction that he came up with a different plan. “This Satan’s drink,” he declared to his advisers, “is so delicious that it would be a pity to let the infidels have exclusive use of it. We shall cheat Satan by baptizing it.”

And so it came to be that despite our vast ideological differences across regions and cultures, we can at least all agree on one thing: coffee is a deeply spiritual experience.

2.

It’s not that I didn’t always have a strong connection with my eldest daughter. It’s just that recently, as she’s running headlong into her fifth year of life, we’ve started to connect in ways I didn’t expect. For example, this weekend we spent most of early Sunday morning building Lego models together. How did that happen? How did she suddenly get into stuff I remember liking as a child?

I know everyone always talks about how quickly kids grow up. I don’t agree with that at all. Growing up takes a long time. But I do find these sudden jumps in growth quite surprising sometimes. I feel like I should be better prepared for each jump so I can catch her if she stumbles. I guess that feeling will never go away — especially when she starts dating. Man. That’s going to be rough.

Anyway. A few weeks ago my wife brought the girls to our office for a visit one morning. I made my daughter a Babycino (frothed milk + hot chocolate sprinkles), and myself a Cappuccino. While I was making the coffee drinks my daughter sat at the table and asked me questions about what I’m doing and how the espresso machine works. I talked to her about bean extraction and crema and milk steaming, thinking that it would bore her to tears. But she was really into it. So I kept going and we ended up having a conversation about craft and why it’s cool to take your time to learn how to do things well and how good it makes you feel when you really master a skill.

3.

I can’t remember when my obsession with coffee started. I just know that one day I started reading books about coffee history, and the best ways to brew a good cup. Then I bought an AeroPress and starting Googling for recipes. Next I bought a grinder, and a Chemex, and became annoyingly picky about beans. And before I knew it, I was that guy at dinner parties. The guy who makes you stop what you’re doing to explain where the coffee came from, how I was going to prepare it, and what they should look for when they taste it. But mark my words: when you do eventually taste the coffee you instantly forget how weird I am, and instead start talking about the unexpected party in your mouth (A guest once remarked that it tasted like angels peeing on his tongue. It is, perhaps, my proudest moment).

Charles Maurice de Talleyrand-Périgord — the Prime Minister of France during the early 1800s — once wrote a completely over the top description of how coffee made him feel. Even though he was very likely under the influence of a vast amount of caffeine when he wrote these words, I swear when I’m drinking a great cup of coffee I want to nod in vigorous agreement:

A cup of coffee detracts nothing from your intellect; on the contrary, your stomach is freed by it and no longer distresses your brain; it will not hamper your mind with troubles but give freedom to its working. Suave molecules of Mocha stir up your blood, without causing excessive heat; the organ of thought receives from it a feeling of sympathy; work becomes easier and you will sit down without distress to your principal repast which will restore your body and afford you a calm delicious night.

Yes, the taste of a good cup of coffee is amazing, but it’s about so much more than that. Most of the joy of any craft — and coffee is no exception — is how you get there. My obsession gave me much more than the ability to make a decent cup. The process — the grind, the bloom, the slow pour — is now a comforting ritual that I associate with mindfulness. It’s a deep mental breath to allow my brain to process what’s going on around me. Most of us spend our days being outlandishly busy. But as with all crafts, during the 10 minutes it takes to make a pot of Chemex, nothing else exists. Time slows down, and I’m focused on getting every detail right. Making coffee keeps the chaos out for a few minutes every day — and it helps me focus when I return to my work.

What is your craft? It doesn’t have to be coffee. But is there something that takes you away from this world for a few minutes every day? Something that’s hard enough that it takes such intense concentration that you (gasp!) even forget to check Twitter? Something with a knowledge well deep enough that you’ll never reach the bottom? Those kinds of obsessions are healthy and necessary because they keep us on our toes, curious, always growing, always learning, always grounded because you can’t win a craft. There is always more to learn.

4.

What you get from craftsmanship is not the end of the story. Despite its many personal benefits, I’ve found craft to be surprisingly social. Hours after my family’s visit a few weeks ago I was still thinking about the brief time I had with my daughter that morning. I couldn’t help but feel like it was significant, and that I should create more of those types of moments with her. And not just with her, but with friends and colleagues too. A discussion about craft — especially if it happens around that craft — usually leads into a discussion about passion, and that easily spirals out of control to anything from a new appreciation of life to brilliant product ideas. As people who create software, those discussions can be invaluable for the work we do.

So here we are: our lives intertwined with a drink that had the potential to divide nations, but instead ended up being the catalyst for the creation of many newspapers and universities; the common element in countless debates, first dates, and last dates; and the ever-present, unassuming ingredient to any everyday conversation or meeting. This hellish heavenly brew might just be the perfect ambassador for the value of learning and practicing a craft. It doesn’t just show us how much we personally have to gain from constant learning and a focused mind. It also shows us how a big part of the joy of craft is found in the gathering of people around its edges, and the ideas that are sparked and shared as a result. Let’s actively create and seek out those moments of shared passion for the world and all we get to do in it.

Preferably around a cup of coffee.

Book Excerpt: Making It Right

As I’m sure you’re extremely tired of hearing by now, I recently wrote a book on Product Management. For those of you who are too cheap to buy it (I kid, I kid1), there is now an edited chapter excerpt up on Smashing Magazine. In Why Companies Need Full-Time Product Managers (And What They Do All Day) I give my definition of Product Management, and go into some of the characteristics of a good PM. Also:

The truth is that, to be effective, the role of a manager for a particular product or area must not be filled by multiple people. It is essential for the product manager to see the whole picture — the strategic vision as well as the details of implementation — in order to make good decisions about the product. If knowledge of different parts of the process resides in the heads of different people, then no one will have that holistic view, and all value will be drained of the role.

Enjoy the freebie!


  1. But not really. PLEASE BUY IT