Ian McAllister states a common rallying cry of the Lean movement in his answer to the Quora question What should a lean startup functional spec / product requirements doc look like?:

Functional specs or product requirements documents invite scope creep and are walking dead documents.

I’d like to start my rebuttal with something Joel Spolsky wrote in Painless Functional Specifications – Part 1, back in 2000:

Failing to write a spec is the single biggest unnecessary risk you take in a software project. It’s as stupid as setting off to cross the Mojave desert with just the clothes on your back, hoping to “wing it.” Programmers and software engineers who dive into code without writing a spec tend to think they’re cool gunslingers, shooting from the hip. They’re not. They are terribly unproductive. They write bad code and produce shoddy software, and they threaten their projects by taking giant risks which are completely uncalled for.

Having said that, I’ll admit that the majority of specification documents are bad. Meaning they are long, they are boring, they are done just to check a box to say they were done, they are written once and never updated, and most importantly, they don’t get used during development. That is a situation Product Managers desperately need to avoid. If a spec isn’t being used actively during development, it’s not the developer’s fault, it’s the Product Manager’s fault. It’s up to the Product Manager to understand what kind of document would be useful to developers, and then provide such a document — one that is much, much better than winging it.

The Functional Spec describes how a product works from a user’s perspective. It’s not focused on how it will be implemented (that’s covered in the Technical Spec), but on defining flows and screens, and how users will experience the product. This might sound a bit academic to some, and against the spirit of the Lean movement that’s all about “getting out of the deliverables business”, but we have to remember that documentation isn’t bad. Bad documentation is bad. Good functional specs help teams communicate, save time, and build better products. But to make sure your functional specs fall into the “good documentation” category, there are a few important points to remember:

• Specs should be dynamic. They are not written once and forgotten about. This is why specs shouldn’t be written in Microsoft Word (no more “v27_FINAL4.docx” filenames). Instead, use collaborative tools like a Wiki or Google Docs to make it easier to edit and access the most recent version.
• Specs should be accessible. The spec document isn’t something that the PM writes in isolation before coming down the mountain to hand over their “Ten Commandments” to the development team to implement. Anyone in the organization should be able to access the specs at any time, and team members should be able to ask questions and contribute to the spec. That’s another reason why Word is out, and online collaborative tools are in. Seriously, uninstall Microsoft Word.
• Specs should be flexible. The biggest and most valid criticism of most functional spec documents is that they are too rigid. Most are merely a list of requirements that were written by people far away from actual implementation, and once their job is done, they are unable to adapt in the face of reality. That’s not how it should work. The last 20% (or more) of a spec is always going to happen during development. That’s not only normal, it’s healthy. It means that teams can adapt to the needs of the products and users, and that they are willing to remove, change, or add features if needed (i.e. if the user evidence or business need is there).

The spec isn’t a document that the PM writes the day before development starts. This is a document that is started as soon as a new project kicks off. Create a template in your wiki (or wherever the plan is to store specs), and open it up as soon you start working on a new project. The best way to write a spec is to add information to it as it becomes available. Add the customer journey map as soon as you have it. Add sketches as soon as you move into the prototyping phase. This reinforces that idea that it’s a living document that is open to collaboration, and it also breaks up the workload so that it doesn’t feel like a huge effort to create the spec.

It’s essential to only add relevant content to the spec — nothing more. For some smaller projects it might be ok to skip the customer journey and prototyping phase, and move straight from sketching to graphic design and/or development. That’s ok. Don’t think of the different sections that make up a spec as above the law, think of them as an a la carte menu that you can pick and choose from based on the needs of the project.

Many people roll their eyes at functional specifications, believing it’s part of an old school way of doing Product Management that isn’t relevant any more. But I’ll repeat what I said earlier: specs aren’t bad. Bad specs are bad. If you create documentation that people actually use to build the product and understand why certain decisions were made, how can you argue that it’s not useful? So my advice is, don’t stop writing specs. Just start writing really good ones.

I’m currently working on a Product Management book, to be published by Smashing Magazine early next year. In the book I go into much more detail on the ingredients of a good functional spec. If you’re interested in getting notified when the book comes up, you can sign up here.

A big thanks to Igloo for sponsoring Elezea’s RSS feed this week. Check them out!

Stop waiting for your IT department to move off SharePoint and start using an intranet you’ll actually like. Igloo is free to use with your team, it’s built around easy to use apps like blogging and file sharing, and it has social tools built right in to help you get work done.

It works on your desktop, your tablet and your phone. Inside or outside of your office. With your team or with your customers. Igloo is 100% white label, so you can make it look like your brand (with your developers or our in-house design and services team).

And if you’re in San Francisco, come learn how a social intranet can help your business succeed. Hear real world examples from our customers, technologists, and writers from Forbes and The Huffington Post. Our Social Intranet Tour hits San Francisco on October 15. We hope to see you there.

Sponsorship by The Syndicate.

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. I’m really into coffee. And this morning my wife brought the girls to our office for a visit. I made my daughter a Babycino (frothed milk + hot chocolate sprinkles), and I made myself a flat white (both pictured above). While I was making the 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 coffee extraction and crema and milk steaming, thinking that would bore her to tears. But she was really into it. So I kept going and talked to her 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 something.

They left hours ago, but I’m still thinking about the brief time I had with my daughter this morning. I can’t help but feel like it was an important moment, 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.

A big part of the joy of learning and practising a craft is the gathering of people around its edges, and the ideas that are sparked and shared as a result. We should actively create and seek out those moments of collaborative creative thinking.

I’m mesmerised by the animations in iOS 7, and none more so than the experience of opening and exiting an app within a folder. To me, it feels like you’re doing Parkour through your apps, deftly using your surroundings to propel yourself forward and maintain as much momentum as possible.

It’s also a great example of iOS 7’s depth, and proof that the design is not as flat as most people would have us believe. Justin Williams sums this up really well in his post Layer Cake:

iOS 7 is designed to be a backlit experience that has each view stacked on top of the previous one based on its z-axis. […]

You’re seeing a lot more focus on transparency and blurs so that you can continue to see the content underneath your front-most view. Modal view controllers are no longer primarily taking over the screen entirely allowing you to maintain a sense of where you came from.

Calling iOS 7 non-innovative seems really short-sighted to me. I think it’s the start of a new, much more understandable metaphor in software design, and I can’t wait to see where it ends up.

This isn’t a zombie blog¹. Still, I’d be doing you a huge disservice if I didn’t tell you about two excellent zombie books I read recently. The books are great because yes, they have zombies in them, but they’re not actually about zombies. They’re about how humans treat each other when we turn on each other. How it’s easy to speak about our values but a bit harder to stick to those values when the going gets really tough. And that’s a topic worth exploring.

The first book I want to recommend is World War Z. The BOOK, not the movie! I saw the movie, and it’s fine, but it is not even remotely similar to the book. I don’t even know why they kept the title. It’s really strange. You should still see the movie, because it’s fun, but the book is something completely different. It is, as the subtitle promises, “an oral history of the zombie war”. The war happened. It’s over. This is a book about people reflecting on what went down. And it is fascinating.

There are commentaries about the media:

The only rule that ever made sense to me I learned from a history, not an economics, professor at Wharton. “Fear,” he used to say, “fear is the most valuable commodity in the universe.” That blew me away. “Turn on the TV,” he’d say. “What are you seeing? People selling their products? No. People selling the fear of you having to live without their products.” Fuckin’ A, was he right. Fear of aging, fear of loneliness, fear of poverty, fear of failure. Fear is the most basic emotion we have. Fear is primal. Fear sells. That was my mantra. “Fear sells.”

There are commentaries on what happens when “knowledge work” is not needed any more:

You’re a high-powered corporate attorney. You’ve spent most of your life reviewing contracts, brokering deals, talking on the phone. That’s what you’re good at, that’s what made you rich and what allowed you to hire a plumber to fix your toilet, which allowed you to keep talking on the phone. The more work you do, the more money you make, the more peons you hire to free you up to make more money. That’s the way the world works. But one day it doesn’t. No one needs a contract reviewed or a deal brokered. What it does need is toilets fixed. And suddenly that peon is your teacher, maybe even your boss. For some, this was scarier than the living dead.

And what happens when those workers relearn how to do stuff with their hands:

It gave people the opportunity to see the fruits of their labor, it gave them a sense of individual pride to know they were making a clear, concrete contribution to victory, and it gave me a wonderful feeling that I was part of that. I needed that feeling. It kept me sane for the other part of my job.

And finally, on freedom:

Freedom isn’t just something you have for the sake of having, you have to want something else first and then want the freedom to fight for it.

The deep thought that went into this book results in an engrossing story full of detail that makes you think about your everyday relationships, and what might happen if those relationships are strained beyond their limits. I loved it.

The second book is The Passage. First, the backstory is great. The author first began developing his ideas for the book when his daughter asked him to write a book about a “girl who saves the world.” Well, it’s about a girl, and she tries to save the world, but it’s like no hero story you’ve read before. It starts when the zombie apocalypse picks up steam, and then jumps ahead 100 years to focus on how one isolated community is dealing with the aftermath. In contrast to World War Z, the war is very much not over in The Passage. It’s gruesome at times, but again, beautifully written.

From interesting reflections on what zombies represent:

What were the living dead, Wolgast thought, but a metaphor for the misbegotten march of middle age?

To what it means to believe in the future:

A baby wasn’t an idea, as love was an idea. A baby was a fact. It was a being with a mind and a nature, and you could feel about it any way you liked, but a baby wouldn’t care. Just by existing, it demanded that you believe in a future: the future it would crawl in, walk in, live in. A baby was a piece of time; it was a promise you made that the world made back to you. A baby was the oldest deal there was, to go on living.

And the nature of hope:

Courage is easy, when the alternative is getting killed. It’s hope that’s hard.

The Passage is not just a great story (I couldn’t put it down), but also another interesting look at what happens when circumstances bring out the worst (and the best) in humans.

All this got me thinking again about an article I read recently about the Zombie Renaissance in literature. And I realised how true this part is about these two books:

We are living in a time when what counts as “life” is in significant scientific dispute, and in the heyday of zombie computers and zombie banks, zombie this and zombie that. Why wouldn’t we also be living in a time of zombie literary forms? Whatever their specific emphases and intricacies, all these zombies represent a plague of suspended agency, a sense that the human world is no longer (if it ever was) commanded by individuals making rational decisions. Instead we are witnessing a slow, compulsive, collective movement toward Malthusian self-destruction. Of course all monsters are projections of human fears, but only zombies make this fundamentally social and self-accusatory charge: we the people are the problem we cannot solve. We outnumber ourselves.

If this is an idea that interests you, I highly recommend these books. Even if you don’t like zombies, you’ll appreciate the thoughtful writing and gripping stories. Do it.

We recently had an opportunity to work with one of my favorite companies, Praekelt Foundation. They do amazing work with projects like MAMA (using mobile technologies to improve the health and lives of mothers in developing nations) and TxtAlert (automated, personalized SMS reminders to patients on chronic medication).

One of their products is called Vumi — a conversation engine for the delivery of SMS, USSD (Star Menu), and chat messages to diverse audiences. Vumi is a custom development platform that usually requires Praekelt involvement to set up, but they also have a self-service portal called Vumi Go, which they wanted to improve and scale so that they can move more of their clients to self-service. And that’s where Flow comes in. Towards the end of last year we started working with the Praekelt team on a redesign of the Vumi Go interface (you should follow Simon and Ben, they’re great). The internal Flow team consisted of me and Philip.

This is one of the hardest interface problems we’ve ever encountered at Flow. Which means it’s exactly the kind of project we love working on. We were tasked with taking some very low-end mobile technologies (SMS and USSD), along with IM (Gchat in particular), and create an easy interface on top of that to allow people to not only understand how the technology works, but also to create complex conversations and surveys using these technologies.

So, we dug in. We started by working with the team to create Personas for the Vumi Go product, so that we could always keep top-of-mind who we’re designing for. Our first goal was to come up with dimension that accurately reflect the different types of people who use Vumi, and would be inclined to go self-service:

We ended up identifying and fleshing out three target Personas for Vumi Go: The NGO with very little technical knowledge, the NGO with significant technical knowledge, and the social entrepreneur. Here’s our Low-tech Persona:

Our next step was to create the ideal customer journey map for the Vumi Go experience. We wanted to outline how people find out about Vumi, and how we can guide them through this complex flow in the simplest possible way. We started with a lot of sticky notes on a whiteboard to define all the possible actions that users needed to perform to set up their conversations. We then proceeded to order those steps in a way that makes the most logical sense (and would allow us to progressively disclose the right information at the right time). This was an essential step because the process of setting up a campaign in Vumi Go can be quite overwhelming, so it was imperative to figure out the right order of steps. That’s why sticky notes were such a great initial approach, since we could move things around at will:

Those sticky notes eventually turned into a user journey sketch on the whiteboard, once we were getting sure about the best way forward:

After quite a bit of discussion and refinement, we got to a journey map that we were happy with. This version is too small to give much detail, but it gives a general idea of what we were building for:

This also allowed us to start working on the Information Architecture. Since we used the journey map as the starting point for the IA, we were confident that we had a good handle on the screens we needed to design, and the order of those screens:

One detail I want to point out here is that we also defined what our deliverables will be for each screen — Sketch, Prototype, or PSD. We find this step really important to avoid miscommunication and surprises down the line.

Armed with a solid user journey and Information Architecture, we were finally ready to start designing the interface. We really needed this upfront time to define the problem properly, otherwise we would’ve gotten stuck along the way and it probably would have resulted in tons of rework. We did our sketching with the team using a combination of white board and paper, so that we could quickly try out different solutions without feeling too bad about the many designs we erased/threw out:

Once we eliminated the designs we believed wouldn’t work well for our target Personas, and settled on a concept we wanted to refine further, we started building an interactive prototype in Axure so that we could test it with real target users. We went through 22 iterations in total before settling on a direction we were confident about. Each of those iterations were based on either internal or user feedback.

The user testing phase was quite tricky. We could do some of it locally in our lab, but most of it had to be done remotely, since the target users reside in places like Kenya and Nigeria. We ended up using TeamViewer for the remote tests, but honestly, we won’t do that again. I’d much rather use Google Hangouts (or Skype screen sharing as a second prize). Teamviewer was just such a mission to set up, and it doesn’t deal well with less-than-perfect internet connections. Google Hangouts seem to be a lot more forgiving when Internet connections slow down (in low-bandwith situations it reduces video quality before it reduces voice quality).

Below is a screenshot of one of the prototype screens. If you’d like to play around with one of the prototypes yourself, you can do so here.

One thing we realized pretty early on is that this is utility, and it needs to be treated as such. Our research showed that people wanted to get through this process as quickly as possible. The complexity forced us to strip out any kind of ornamentation out of the interface. Not that we set out to make an ugly interface, but there were many decisions we had to make in the interest of utility and usability over “look and feel” (sorry, I hate that term too).

During the final stages of prototyping we started working on Style Tiles to get a sense of the graphic direction of the application. Style Tiles are a great way to discuss graphics without getting bogged down in UI details, since it’s not concerned with layout but exclusively with interface elements: typography, color palettes, button behavior, etc. Here’s an example of one of the Style Tiles that Philip created:

Once we had a refined prototype based on user testing, as well as Style Tiles to guide the graphic direction, it was fairly easy to go to the PSD stage. The prototype and strong style guide also allowed us to not have to create the entire site in Photoshop. We could just create a few key pages, and rely on the rest of it to be defined during development (yep, I admit we’re not quite Post-PSD). Here are a couple of examples of the graphic design:

Again, as you can see, there’s nothing flashy here, and that’s by design. Based on our Personas and user journey, our conscious decision was to create this web application as an easy-to-use utility. It’s not a general consumer site, and it’s not an e-commerce site — it’s an essential cog in the larger machine of what businesses (and NGOs in particular) need to accomplish.

At this point the Praekelt developers (who were involved throughout) took over the process to get the application live. Ben talks about the development of the site more on the Vumi blog (see The inside scoop on our recent Vumi launch), so I won’t cover that here. I’ll just end by saying that this is one of the most gratifying projects I’ve ever worked on. We always talk about doing meaningful work in the design community, and this was one of those projects where we absolutely know that the product we helped build is going to affect people in a positive way. And the fact that it was such a hard problem to solve only made the experience better.

Congratulations to the Praekelt team on their relaunch. From everyone at Flow, we love you guys.

My thanks to Booking.com for sponsoring Elezea’s RSS Feed again this week to promote their career opportunities.

Forgive the cliche, but coming to work for Booking.com has been one of the best decisions. Within a week of arriving to the Netherlands, I had already created two UI experiments and pushed code to the live site. It was intimidating and thrilling at the same time. Those feelings haven’t left. I’m constantly humbled by the more than 300 super intelligent colleagues of 51+ nationalities! I learn every day. If there’s a day I don’t? It means I wasn’t in the office.

The warmth and acceptance of new hires is brilliant. I was invited for chess, football, drinks, and even knitting, within a fortnight. Friday after work drinks can easily evolve into an adventure anytime. There’s always something to do in this city. And at Booking.com, there’s always someone who’s willing to join in. The many parties are just something that has to be experienced. Come join and I’ll show you around!

Sponsorship by The Syndicate.

Why Generation Y Yuppies Are Unhappy is such a brilliant post. Funny, way too true, and great illustrations. It follows the story of Lucy, a fictional Gen Y yuppie who is not having such a good time right now. This part about social media sites (or what I guess is known as Facebook image crafting) really stuck with me:

Social media creates a world for Lucy where A) what everyone else is doing is very out in the open, B) most people present an inflated version of their own existence, and C) the people who chime in the most about their careers are usually those whose careers (or relationships) are going the best, while struggling people tend not to broadcast their situation.  This leaves Lucy feeling, incorrectly, like everyone else is doing really well, only adding to her misery

So that’s why Lucy is unhappy, or at the least, feeling a bit frustrated and inadequate. In fact, she’s probably started off her career perfectly well, but to her, it feels very disappointing.

I increasingly feel like Facebook has become a cacophony of ads and fake happiness, and I’m extremely turned off by it. I’m trying out Path again (I know, hypocrisy!), and I’m enjoying the quietness and sincerity there. It’s such a stark, appealing contrast to the endless shouting on Facebook.