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.

Horace Dediu makes an interesting point about some of the new iPhone 5s features in M is for Mystery:

Perhaps this is why Apple chose to describe the iPhone 5s as “forward-thinking”. The M7 and the Touch ID are like research projects whose actual value will be realized at some future time, in probably different contexts.

Sisir Koppaka takes this idea further in The Most Forward-Thinking Apple Yet. On going 64-bit:

I don’t believe Apple added 64-bit support to iOS 7 and all their apps just to prepare for an eventual transition to 4GB+ memory capacities in future iPhones. I think this was to do with something more impending. Do we know any product category that Apple would be interested in, that would require the use of both iOS and an A-series chip that is 64-bit capable in order to address 4GB+ memory? Apple TV (the one that is yet to come, not the one that exists).

And on the M7 processor:

The new CoreMotion Framework for iOS 7 adds a step counter and a motion activity detector (stationary, walking, running, vehicle or unknown). We know that Apple has been hiring experts in noninvasive blood component measurements. We know they have a patent on a wrist watch. The iWatch must not be far away.

This is a pretty daring thing for Apple to do. Instead of focusing on what is hot now, they are releasing a product that reveals their vision for the future without it having the capabilities needed to deliver fully on that future. It’s a long game, it’s a gamble, it’s gutsy, and it’s probably going to work once developers start experimenting.

I agree with every glorious word in Erika Hall’s How the ‘Failure’ Culture of Startups Is Killing Innovation. It’s a brilliant and impassioned defense of making design research part of every product development process:

Somewhere along the way, it got to be uncool to reduce one’s risk of failure.

Part of this may be because the risk of failure is dramatically lower than it used to be. But another reason is that many people don’t actually understand what research is, and have somehow conflated concepts like “rapid prototyping,” “lean startup,” “minimal viable product,” and “[insert] other smart-sounding thing to do” with avoiding research.

It’s really hard to not just go ahead and quote the whole article, because it’s so good. I’ll leave you with just one more bit and an enthusiastic recommendation to read the whole thing:

Maybe knocking out a prototype or building a company is the fastest, cheapest way to learn. But often it’s not. Sure, a prototype can tell us if the user understands the potential solution — but if it’s solving a problem no one has, why bother building it in the first place?

Ok, I lied. One more bit:

It becomes immediately apparent, when we try to understand our fellow humans through research, that we are not rational creatures. But when it comes to making business decisions, research helps address that irrationality and increases our chances to succeed. And make no mistake: in a world where design makes or breaks success, all product design decisions are business decisions. Asking the right questions will lead to useful insights.

More than a few people seem to be confused about the pricing strategy for the iPhone 5C. There are probably only two articles you need to read about that: John Gruber’s Thoughts and Observations on Today’s iPhone 5C and 5S Introduction, and Ben Thompson’s The iPhone is Apple Doubling-Down On What It Does Best.

But even those articles don’t address a complaint that I’ve seen quite a bit of over the past couple of days: that Apple is trying (and failing) to expand into emerging markets. Here’s an example from a bizarre Memeburn article called Dear Apple, don’t try to be Nokia:

…the iPhone 5C — supposedly targeted at the emerging markets and presented as a low-cost device…

And tweets like this are everywhere:

@RianVDM @bokardo – and our customers can't afford ( well the billion potential customers in emerging markets)

— Kirstin Horton (@KirstinHorton) September 11, 2013

It’s important to point out a few things here.

First, everything flows from the pricing strategy, and the only people calling the 5C a “cheap iPhone” are tech bloggers. It’s not a cheap iPhone. It’s an iPhone that replaces the previous strategy of selling last year’s model at a slightly cheaper price. As Gruber points out:

The prices of the iPhone tiers remain the same as last year. What changes with the 5C is that the middle tier is suddenly more appealing, and has a brand of its own that Apple can promote apart from the flagship 5S.

Second, the vast majority of mobile connections in emerging markets are pre-paid, not contract-based. For example, in Africa 96% of connections are pre-paid (source). This means that in emerging markets people buy phones that aren’t subsidized. The cheapest iPhone 5C costs $549 off-contract. This makes it a virtually unattainable phone in the pre-paid emerging market.

Here’s the thing though: does anyone think Apple doesn’t know this? Is the assumption that Apple is trying to break into the emerging market with a $549 phone? That would be insane, right? But that’s not what Apple is doing at all, and they never said that they are.

The iPhone 5C is not about expanding Apple’s share in emerging markets. It’s about increasing their share of the high-end phone market, while simultaneously increasing their profit margins on those phones because of cheaper manufacturing costs.

So, yes. The iPhone is still too expensive for most of the emerging market. But Apple doesn’t need the emerging market to be insanely successful. They just need to keep selling a ton of phones in subsidized markets at a healthy profit margin. And that’s exactly what the iPhone 5C will accomplish.

Keith Houston’s fascinating essay The Ancient Roots of Punctuation begins like this:

The story of the hashtag begins sometime around the fourteenth century, with the introduction of the Latin abbreviation “lb,” for the Roman term libra pondo, or “pound weight.” Like many standard abbreviations of that period, “lb” was written with the addition of a horizontal bar, known as a tittle, or tilde. And though printers commonly cast this barred abbreviation as a single character, it was the rushed pens of scribes that eventually produced the symbol’s modern form: hurriedly dashed off again and again, the barred “lb” mutated into the abstract #.

Which is why the hashtag is often referred to as the pound sign. Keith also explains the origins of the Pilcrow (¶), the Ampersand (&), the Manicule (☞), and the Diple (>). Great article.

I continue to be fascinated by the smart city movement. The multiplexed metropolis is a very interesting look by The Economist at the pros and cons of connecting cities through open access to all kinds of information:

But clever cities will not necessarily be better ones. Rather than becoming paragons of democracy, they could turn into electronic panopticons in which everybody is constantly watched. They could be paralysed by hackers, or by bugs in labyrinthine software. They could furnish new ways to exclude the poor. They might even put at risk the serendipity that makes cities such creative places, argues Richard Sennett, a sociologist at the LSE, making them “stupefying” instead.

I have to admit that I had to look up the word “panopticon” — and it’s such a great analogy. From Wikipedia:

The Panopticon is a type of institutional building designed by English philosopher and social theorist Jeremy Bentham in the late 18th century. The concept of the design is to allow a watchman to observe (-opticon) all (pan-) inmates of an institution without their being able to tell whether they are being watched or not.

Let’s hope we can avoid this…