Are you building an Android or an iPhone?

The One Question Every Product Manager should be able to answer: Are you building an Android or an iPhone?

Target audience: Everyone involved in making a digital product. Or a physical one for that matter.

In a previous post I discussed the practicality of using a hybrid Waterfall/Agile approach to Project Management when an Agile approach to customer feedback is required for an empathy driven Product Development ethos.

Based on the above it’s worth mentioning we use this narrative in communicating our internal process to the customer stakeholders to help align both our teams with the end game.

By explaining our design ethos each and every sprint review, our reluctance to building any unnecessary features to deliver an MVP at every turn slowly and steadily transforms into a unified objective we find the customer reminding us of whenever our Engineers get excited about a new market trend the customer happens to ask about the feasibility of including.

Below are the major points we cover during EVERY Customer Sprint Review meeting in chronological order:

1. The Project Management Framework (what is Agile)
2. Who we are, who they are, what we’re doing here today, and what we hope to get out of this workshop
3. How we design our products (iPhone vs Android)
4. Nomenclature
   Business Requirements (BRs): what they are & why they should care
   User Journeys: what they are & why they should really care
   Wireframes: why everything looks so ugly
   (customer) Business Owner Priorities vs (our) User Journey Priorities aka In which sequence we choose to build
5. Updated Wireframes based on the previous Sprint feedback
6. Feedback on Wireframes (where we ask the customer to look beyond the squiggly lines & green backgrounds)
7. Next Sprint: BRs, Updated Wireframes, & Stakeholders involved

I think I can spare you the nitty gritty of all of the above and hone in on #3: How we design our products (iPhone vs Android).

What fascinates me about Engineering teams in general is their ability to both care and loath the user at the same time. Being an Engineer myself, I must say I have been tempted to ask the customer after a passionate exchange: ‘have you considered changing the user?’ As apposed to actually owning the nuances of User Experience with a broader Job Story Narrative (more on that in a different post).

Engineering condescendance aside, End Users are quite clear with what their priorities are when presented within the proper context. We normally explain our design ethos to our customers using an iPhone & Android analogy which normally goes as follows:

::Greetings & Pleasantries::

When designing software, there are quite a few ways of going about delivering Business Requirements, or fulfilling your Job Stories. We like to think of the software industry in general adopting one of two approaches for the sake of simplicity:

1. The iPhone Approach (fan boys calm down — we actually mean the iOS approach)
2. The Android Approach

The distinguishing factor between the two being primarily the ease of use, which in fancy talk we describe with cognitive load, or the number of possible decisions the user is allowed to make.

It really helps stakeholders set the tone for how much autonomy is given to the end users during their day to day interactions with the system, taking into account things like processes, procedures, habits, workflows, and the organization’s rate of change which needs to be reflected in the software itself.

Easy/Hard Simple/Complicated Android/iPhone Diagram

To explain the difference between the iPhone & Android design ethos, we need to first explain the difference between Easy vs Simple, and Hard vs Complicated. Spoiler alert, the two pairs are not synonymous as most might think, let me explain how and why.

It only when I understood the difference between the above concepts is when I fully began to understand the importance of removing choice, and in effect cognitive load from the end user, to deliver an Easy to Use product. Even if that meant the user having less control over how to get from A to B.

When you think about Easy & Simple, most people normally equate them avoiding investing expensive mental energy to distinguish the two, they are, however, quite different.

Think about digging a 1x1x1 meter ditch (pronounced 1 cubic meter). There are many ways to go about this clearly set task: Simply, or Complicatedly.

Imagine to execute this seemingly straight-foward task, you were given a tablespoon and told you dig to the approximate measurements of the requested ditch. I don’t think many would argue the task as complicated. Easy on the other hand, would be far from true.

Now consider the option of using a Caterpillar Excavator, state of the art, equipped with IoT soil moisture measuring gears and a gyro stabilised dynamic tilt sensor (impressive isn’t it?), would you describe the process of learning how to use it as simple? I think not. However, once you’ve mastered moving the two dimensional levers appropriately, it’s probably a couple of scoops et voi la! Easy peasy lemon squeezy.

Hence the distinction between Simple/Easy and Complicated/Hard. But how is this relevant to the iPhone you might ask? Well that’s the question we answer every Agile meeting, and I enjoy telling it every time:

What the iPhone does for the users is create a Simple and Easy User Experience by keeping only that which is absolutely necessary in the user experience (Simple), and limits the ways you’re allowed to perform tasks with them (Easy). Which is why you can ask pretty anyone’s grandmother how on the iPhone to raise the volume of a song and you’ll get a single consistent answer referring to the two buttons to the side of the device.

While the Android was built with a whole different ethos, it was built by geeks, for geeks. A platform with freedom in mind. Control given back to the masses in response to the Nokias, Blackberry’s and iPhones of the world which deemed us unfit to make our own decisions.

And they were both right.

If you ask any Android user how to raise the volume, you’ll get one of the following answers:

1. The buttons to the side of the device
2. The controls in the slide down/up menu of the device
3. In app specific volume control
4. The up and down volume buttons on my headphone cable (the side buttons broke last year)

Which means Android gives the user more control and flexibility over how to do any particular task, be it changing the priority on an internal operating system process, to the permissions applied to specific files the device deeply hidden in application data folders. Choosing is hard to perform, even after receiving proper training, making any android definitely more complicated to use.

The principal idea here is simple: People want to make the least number of decisions possible every time they unlock their phones, and if possible, they want a dopamine hit anytime they actually do.

In the words of the late Steve Jobs “It’s in Apple’s DNA that technology alone is not enough — it’s technology married with liberal arts, married with the humanities, that yields us the results that make our heart sing.”

Ultimately every team finds their internal design language, framework, or any other visual representation of the creative liberties and worldly constraints that go into the process of Human Computer Interaction design, but one thing is for sure: The moment your team finds theirs will be synonymous to a music band finding their sound.

Which brings us back to the question every Product Manager should be able to answer: Are you building an Android or an iPhone, and to me, it all depends on what the customer needs it to be.