This site is about everything digital, giving an update on new things as I learn

Category: Apple

If you’d know me personally, you’d know that I love a good list. Making lists helps me to outline my thoughts, see connections and help prioritise. Three years ago, I wrote about “The Checklist Manifesto” by Atuwal Gawande, which is a great book about the importance of checklists and the ingredients of good checklist (see Fig. 1 below).

Why checklists? – As individuals, the volume and complexity of the know-how that we carry around in our heads or (personal) systems is increasingly becoming unmanageable. Gawande points out that it’s becoming very hard for individuals to deliver the benefits of their know-how correctly. We therefore need a strategy for overcoming (human) failure. One the one hand this strategy needs to build on people’s experience and take advantage of their knowledge. On the other hand, however, this strategy needs to take into account human inadequacies. Checklists act as a very useful as part of this strategy.

What makes a good checklist? – Gawande stresses that the checklist can’t be lengthy. A rule of thumb that some people use is to have between 5 to 9 items on a checklist in order to keep things manageable. The book contain some good real-life examples of how people go about starting their checklists. For example, looking at lessons learned from previous projects or the errors known to occur at any point.

How to use a checklist – I believe that the key thing to bear in mind when using checklists is that they aren’t supposed to tell you what to do. As the book explains, a checklist isn’t a magic formula. Instead, having a checklist helps you at every step of the way, making sure you’ve got all the crucial info or data required at each step. Also, a checklist is a critical communication tool, as it outlines who you need to talk to (and why, what about) at each step of the way. Gawande also highlights the value of the ‘discipline’ that comes with having a checklist, the routine that’s involved in having a checklist. I’d add to this that a checklist can be a great way of identifying and mitigating risk upfront.

“In the world according to Steve Jobs, the ANPP would rapidly evolve into a well-defined process for bringing new products to market by laying out in extreme detail every stage of product development.

Embodied in a program that runs on the company’s internal network, the ANPP resembled a giant checklist. It detailed exactly what everyone was to do at every stage for every product, with instructions for every department ranging from hardware to software, and on to operations, finance, marketing, even the support teams that troubleshoot and repair the product after it goes to market.”

I perked up when I read how the ANPP resembles “a giant checklist”, detailing what needs to happen at each stage of the product development process. Apple’s process entails all stages, from concept to market launch. The ANPP is understandably very secretive, but I believe that we don’t need to know the ins and outs of Apple’s product development process to look at the use of checklists when developing and managing products:

Checklists aren’t the same as Gantt Charts! – It’s easy to confuse a short checklist with a Gantt Chart. Over the years, I’ve observed how people can derive a lot of certainty from creating and viewing detailed Gantt Charts or roadmaps (see my previous thoughts on this topic here). In my view, a super detailed checklist defeats the object. Instead, I encourage you to have short checklists that highlight both basic and critical steps to go through when developing / launching / managing products.

Checklists are evolving – Checklists are evolving in a sense that they’re likely to be different per product / team / project / etc. I find, for example, that each time I work with a new team of people or on new product, the checklist reflects the specific steps that need be checked, tailored to the team’s way of working or the specific product at hand.

Checklists are a collective effort – I’m currently onboarding a new UX designer into my team, and he’s keen for us to look at the ‘design checklist’ together, as he’s got some suggestions on how to make it work better. This might mean that the existing design checklist (see Fig. 2 below), underpinned by my preferred dual track approach, might be binned or adapted accordingly. Both are fine, as I expects checklists to be formed by those people who are responsible for checking the different list items. I’ve seen people treat their individually developed checklists as a decree … which others had to following blindly. My simple reaction to that kind of approach: no, no, no, no.

Fig. 2 – Sample ”design checklist”:

Democratise the sign-off process (1) – Often, quality assurance people come up and drive the best checklists. However, the risk I’ve observed, is that these QAs or the product managers become the single sign-off point for the checklist in question. I go into companies and look at their SCRUM and Kanban boards which have cards stating “Pet sign-off” or “Jackie sign-off”. I recently spoke to product managers at a company where the CEO wanted to sign off each feature.

Democratise the sign-off process (2) -Whilst nothing seems wrong with this approach at the face of it, there are two reasons why I feel uncomfortable with this ‘single sign-off’ approach. Firstly, to me, a hallmark of a truly self-organising and empowered team is that everyone feels empowered to ‘sign off’ on the end result (and its individual components). Secondly, I’m also worried about what happens if the designated sign-off person isn’t available. What happens if Pete and Christina are off ill or in never ending meetings? What if the CEO isn’t available for sign-off? Does the feature or product not get released to market? In short, I’m worried about creating another bottleneck or ‘single point of failure’ or forfeiting speed to market.

Don’t forget the basic steps – How often have you’ve been in a situation where you’ve just launched a new product or feature and realised that you forgot to test the styling of the images, content and calls to action? Sense checking things like these sounds like a basic step, but it’s one that’s easily forgotten in the excitement (and haste) to launch. Having basic steps like ‘check content’ included in your ‘pre-launch checklist’ will make sure that things don’t get overlooked (see Fig. 3 below).

Fig. 3 – Sample ”hygiene checklist”:

Include critical steps, lessons learned – I’ve found checklist to be a good way to incorporate key lessons learned on a continuous basis. The risks with post-mortem sessions or retrospectives is that lessons learned don’t get action and tend to be forgotten. Including a learning into a checklist is a simple but effective of way of ensuring that a learning sticks. For example, “training the customer support team” (on a new product, user flow or feature) was a critical step that I used to forget consistently. By including this item in a ‘go-to-market checklist’ helped me and my team in making sure this step wouldn’t be forgotten about anymore.

Put your checklist on a wall – Finally, I’d recommend making your checklist as visible and shareable as possible. You can stick your checklist on an office wall or, if the team aren’t all working in the same space, in collaboration software products like Confluence and Trello (see Fig. 4 – 5 below).

Main learning point: As long as you don’t confuse them with highly detailed project plans or roadmaps, checklists can be a valuable tool in making sure you and your team don’t overlook key steps when developing products!

I always like discovering new apps, playing with them and seeing what works for me and what doesn’t. I recently looked at some apps in the property finder’ space. Julie Zhuo has recently written up a good way to do a “product critique” which template I’ll apply to my app reviews. I recently used the iOS app from Zoopla, a UK based property site, and applied Julie’s product critique template:

How did this app come to my attention? – I looked at the Zoopla site a few years ago, but hadn’t interacted with the site (or the app) since. I’d heard about significant improvements to both the user interface and functionality of the app, reason why I was keen to have a play with the app.

My quick summary of the app (before using it) –Zoopla’s app enables users to find properties to buy or rent in their local areas.

Getting started, what’s the sign-up process like? –Registeringas anewZoopla user was pretty straightforward; only an email address and a password were required for me to register. I noticed that I didn’t need to be logged in to do actions such as messaging the estate agent about a property that I was interested in. This clearly makes it easier for me to quickly enquire about a property.

How does app explain itself in the first minute? – On the app’s opening screen, it clearly says “Zoopla” followed by the “Smarter property search” strap line. Most of he options on the opening menu – ranging from “For sale” to “MyZoopla” – are pretty self-explanatory (see Fig. 1 below). I felt that some of the navigation options could have benefited from some additional explanation. For example, “Current values” and “MyZoopla” could have done with explanatory hover over comment to explain their function and value to users.

How easy to use was the app? – I found it very easy to use the app. When I played with the app, I particularly concentrated on an important use case: finding a property to buy (see Fig. 2 below). The app lets users filter their searches by a number of factors such as price and number of bedrooms (see Fig. 3 below). When you get the results, the app enables both hiding and sorting of the results. Hiding can be particularly helpful if one doesn’t want the same search results to come up time and time again. By default, the search results are sorted by ‘Most recent’ but users can sort by e.g. ‘lowest price’ or by ‘most popular’.

How did I feel while exploring the app? – Zoopla’s app is easy to explore; the navigational items are clearly signposted and the split menu bar meant that I could easily find my way around in the app.

Did the app deliver on my expectations? – Yes, the app was simple and easy to use. It delivered on the main use cases that I expected the app to cover: finding properties, either to buy or to rent. However, the one bit of functionality and information that I missed from the app was the ability for users to sell their properties or put them up for rent through the app. It made me wonder whether this could be because Zoopla’s business model is based around estate agents who submit properties to be listed in the app.

How long did I spend using the app? –I’d say I spent about 15 minutes in total playing with the app.

How does this app compare to similar apps? – Lovely Rentals in the US and Rightmove in the UK are apps similar to Zoopla. I personally find the user interface of the Rightmove app a lot less appealing in comparison; it gives me the feeling that I have to work hard to get the property results that I’m looking for. A good example is the “Sale Filters” screen in the Rightmove app (see Fig. 4 below). At a first glance, I struggle to comprehend what the “advanced” option will do for me or what “Include Sold STC” means. In contrast, I immediately sensed that the Zoopla was easy-to-use and intuitive.

Main learning point: Zoopla’s property app is easy to use and intuitive. It’s a no-frills app which does exactly what you expect it to do. I like the way the app gives it users the ability to easily filter and sort search results. All around, a good and easy to use app!

Fig. 1 – Screenshot of the opening screen of the Zoopla app

Fig. 2 – Screenshot of property listings on the Zoopla app

Fig. 3 – Screenshot of search options when looking to buy property through the Zoopla app

Last week, Apple spent a large part of its keynote at WWDC 2014 talking about iOS 8, its new operating system for its handheld devices. These are the main features that we can look forward to as part of iOS 8:

Touch ID – Apple’s “Touch ID” fingerprint recognition system is currently only available on iPhone 5S but will now be integrated into iOS 8 and will become available on more Apple devices. Instead of having to remember lots of different passwords, with Touch ID users will now be able to complete transactions just using their fingerprints (see screenshot in Fig. 1 below). In addition, with iOS 8 there is a likelihood that users will be able to scan credit cards via an iPhone or iPad camera and automatically fill in their details as part of an online shopping transaction.

Handoff – With Apple’s “Handoff”, users will be able to switch seamlessly between devices; one can start watching something on an iPhone and then continue watching on an iPad, without any overlap or lag (see Fig. 2 below). Another important aspect of Handoff is the inclusion of the Mac, Apple’s desktop, and the notion that the desktop operating system can now talk to an Apple mobile operating system without any friction. For example, it means that when you start working on a document on a desktop, you can easily resume working on the document on your mobile, without having to delve into different folders, etc.

Interactive Notifications – iOS 8 will include new interactive notifications which will allow users to reply to text messages or accept calendar invites without leaving the app that they are in. These new interactive notifications can be invoked from their temporary banner that appears at the top, as well as on the lock screen (see Fig. 3 below).

Health – At last week’s WWDC, Apple presented it’s new Health app and a developer focused Healthkit API. The Health app effectively aggregates all your health and fitness data, irrespective of the apps that you use to generate this data. Examples of popular fitness/health apps are Fitbit are FitStar and their data can be aggregated into a secure dashboard on your Apple smartphone or tablet (see Fig. 4 below). With the Healthkit API, developers can start integrating the data of health/fitness apps with Apple’s Health app.

HomeKit – With the “Homekit”, Apple is taking a firm leaf out of Nest‘s book. Nest is all about creating a connected home and which home products are designed to learn from user behaviour (I wrote about Nest earlier in the year). The technology which underpins Apple’s HomeKit is very complex, but in essence it covers one or more ‘Homes’, with different ‘Rooms’ within the Home. For example, you can have a room called “Master Bathroom” in your Home and you can have two distinct actions which you can trigger through Siri, Apple’s voice command technology: (1) closing the bathroom door and (2) turning on/off the bathroom light.

Main learning point: Apple has introduced some interesting features as part of it’s new iOS 8 operating system for its handheld devices. Perhaps the least sexy one out off all these features, but the “Handoff” connectivity feature is a really critical one as it will enable users to seamlessly switch between Apple devices and desktop. If I were to go for ‘sexy’, then Apple’s forthcoming Health app is probably the most exciting, both from a user perspective and from a data aggregation perspective.

The ‘iBeacon’ is Apple’s recent product which uses location-sensing technology to help extend location services within the iOS operating system. For example, with the help of an iBeacon an iOS device or other hardware can alert its (location based) apps when a user leaves or enters a certain location. Also, when a user is getting closer to a specific location (e.g. a store checkout) a user’s app can work out the proximity to that location.

Currently, a large number of devices still use latitude and longitude to work out a location. The iBeacon uses bluetooth signals instead. More specifically, the iBeacon works on Bluetooth Low Energy which means that the power used is considerably less compared to ‘traditional’ bluetooth signals.

The question arises how this location-based technology can best be used. Let’s look at some potential use cases:

Enhancing your shopping experience – Companies like Sonic Notify and Estimote specialise in so-called “proximity based marketing”; people will get targeted alerts on their smartphones whenever they enter a certain area (see Fig. 1 below). Another great example in this respect is shopBeacon which can welcome a shopper when he/she enters a store and show the shopper location-specific deals, discounts, recommendations, and rewards, without the shopper having to remember to open the app. Equally, if a shopper likes a specific product in the app, shopBeacon can remind him/her when she enters the store that sells it (see Fig. 2 below).

Linking digital content to the physical world – You won’t need an iBeacon every meter or so to figure out where a person is located. As explained in this great article in Wired, you can have a number of beacons quietly triangulating your position at distances anywhere from 100 feet down to just a few inches. This technology opens the door for a range of new digital experiences based on so-called “microlocation”. A good example is the “Bar Kick” pub in London where certain magazines will become available automatically and for free via Apple’s “Newsstand” as long as you’re in range of the pub’s iBeacon.

Seamlessly connecting all your devices – Perhaps this use case is one that it’s a bit further down the line, but one can envisage iBeacons facilitating a smooth linking of all your gadgets and accounts. Gone will be the days of having to use lots of different logins, passwords or WiFi credentials. Instead, iBeacons will automatically pick your device and link to your account.

Main learning point: Personally, I find the iBeacon one of the most interesting and promising innovations that I’ve seen in a while. It might take some time but I do believe that these beacons will transform they way we do everyday things such as shopping, using public transport or connecting with other devices. I can foresee a range of new applications popping up, all making content and interactions a lot more targeted, contextual and personalised.

So I had designed and developed a minimum viable product for my HipHopListings iOS app. I had worked very closely with Alex the developer, designed the mobile workflow and outlining the way I expected users to interact with HipHopListings on their iOS devices. I tested, tested and tested. It led to some critical bug fixes and improvements to both the back-end and the front-end of the app.

My jaws dropped when Apple approved my HipHopListings app within less then a week after submitting it. You can find the app here and I’ve added a screenshot below (see Fig. 1). Based on my previous experiences with getting apps approved by the mighty Apple, this was super fast!! I celebrated and felt like the proudest man on the planet as I’d just launched my own app and had been able to do so within less than a month from actually designing the app screens!

However, I realised that I couldn’t just rest on my laurels and had to start measuring if and how people were actually using my app. If I wanted to learn about how to best improve my app, I really needed to start measuring things, but where to begin!? I had implemented Google Analytics but wondered what metrics to focus on, especially as there are countless analytics ratios and reports to choose from.

I decided to try and identify my key questions and assumptions that I wanted to validate first:

How many people are using my app on a recurring basis? – My simple reasoning was that the number of people who had installed my app (which numbers are available via iTunes Connect) is pretty meaningless when those people never use the app again. I therefore wanted to be able to do some form of cohort analysis to get a better understanding of the usage patterns of new users, developing an insight as to wether my app was compelling enough for people to keep coming back to it.

Where are most HipHopListings users based? –One of my underlying assumptions when creating the app was that the bulk of HipHopListings’ target audience were likely to be based in the UK, especially given the fact that the “Shows” screen on my app only lists UK gigs. I now wanted to find out whether this assumption was actually true. Is most of the (recurring) usage coming from the UK? If not, what can I do to attract more UK users to the app? Is there a particular reason that people use (or don’t) use the app?

Which screens do users tend to look at most? – I felt that looking at screen views (and the duration of each view) could provide me with a better indication of where the app could be improved. When I started creating the HipHopListing app, one of my assumptions was that people would mostly use the app to view upcoming Hip Hop shows (this assumption was part of the opportunity assessment that I did before deciding to build the app). Was this actually true? If I started making slight changes to the “Releases” screen, would these have an impact on the performance of the screen that lists upcoming releases?

What are common drop-off points in the app? Again, I believed that if I wanted to get a better insight into the understanding of my new app, I’d need to understand the common drop-off points within the app: where do users typically lose interest and why?

Main learning point: I realised as I was thinking about the kinds of things that I’d like to measure about my HipHopListings app that I was falling into a classic ‘data trap’. My thinking was very much around specific questions that I hoped would give me a better insight into the performance of my app. However, I’d forgotten to think about goals, setting some sort of benchmark or baseline of what success should look like for my app. I thus learned that it would be good to first take a step back and identify my main goals, before deciding on the right things to measure.

Now that my efforts to develop the HipHopListings iOS app myself had not provided me with the desired results, I decided to seek help. I got as far as creating a basic app version of my existing HipHopListings (‘HHL’) blog and installing it onto my phone. However, it became pretty clear very quickly that Apple weren’t going to accept my app or that “AppMaker”, the 3rd party tool I was using, were going to submit the app for me. Alex, an experienced end-to-end developer, was happy to help me with developing the app in return for a modest fee. One of the first questions that he asked me however was whether I could provide me him with a short brief of what to build.

At this stage, I had thought about my product vision, assessed the opportunity, created wireframes and even started developing the app myself. What I hadn’t done, however, was define the minimum functionality which needed to be included in the app. I thought I had a reasonably good idea of my target users and their problems that I was looking to solve through the app. Also, I felt I now had a better steer on the criteria Apple use to approve an app into their App Store. I just needed to translate this is into some well-defined features and requirements that Alex could work against.

The challenge was to rein myself in whilst I was outlining the product requirements. I could easily see myself falling in the trap of overdesignining this app, now that I had an experienced developer to help me. I therefore used Tristan Kromer’s version of a mix of the “Lean Product Canvas” (by Ash Amaurya) and the “Business Model Canvas” (by Alex Osterwalder) as a technique to try to keep my requirements as ‘lean’ and ‘minimal’ as possible. This is how I broke it down:

Customer needs and goals (problems) (1) – The key user problems I was looking to address through my HHL app were twofold: (1) how do I find out about upcoming Hip Hop shows in my area? and (2) how do I find out about upcoming Hip Hop releases. Both seemed like fair assumptions to make as I’ve received lot of a feedback on these problems from having done HHL over the past 4 years.

Customer needs and goals (requirements) (2) – In my brief to Alex the developer I translated the user problems mentioned under 1. in the simplest way possible: (1) enable users to easily view upcoming shows and go to a 3rd party ticketing site (see Fig. 1 below) and (2) enable users to filter listings by area and by date (see Fig. 2 below). I also asked Alex to set up Google Analytics so that I could track users’ actual behaviour and validate some of my assumptions.

Keep it simple – I decided to keep the design of the app as simple as possible at this stage. Let’s get the app approved by Apple first (which can be a real pain in itself), get people to use the app and comment the functionality. Once I’ve established that users actually do find the app of value in terms of finding out about gigs and releases, I can them improve the functionality further and worry more about the user interface / visual design. In his “Lean Product Canvas” Tristan Kromer refers to this approach as ‘trimming the fat’.

Customer needs and problems (3) –Based on previous feedback, I thought it would be good to add a very basic ‘discovery’ element to the app; a very simple ‘Featured’ screen which users can turn to for curated shows and releases which I’d chosen to highlight (see Fig. 3 below). I reckoned this feature would be relatively easy to get feedback on. Firstly, through tools Google Analytics and Flurry I would be able to monitor the number of views of this screen. Secondly, I felt this would be the kind of feature which would be easy to get qualitative user feedback on. I could use both feedback methods to validate one of my assumptions: making it as easy as possible for users to discover new shows and releases will be a powerful proposition for HHL’s (target) users.

Constraints to consider – One of my personal goals was to learn more about designing for mobile. And learning I did. My original design went largely out of the window as soon as I realised from testing that Facebook’s more traditional split screen view (see Fig. 4 below) would probably be easier to implement and for users to interact with. After all, all I wanted is a clean and simple interface, no frills, and it looked my original designs were probably a bit too elaborate compared to some of the simple user interfaces that are working well (with Facebook, Hailo and Vine as good examples). Also, I realised that I had to update the app’s content manually via a back-end which had to be kept as simple and intuitive as possible. I spent a good chunk of my time think about the user flow involved in uploading, updating and removing the app’s content.

Main learning point: actually putting down my functional and non-functional requirements down was both scary and exciting at the same time. Scary, because I really had to rein myself in and be realistic about technical and financial constraints. Exciting because I could apply some of my ‘lean’ lessons learned to my own app and think about the key value I could provide my (target) users with in the first iteration of my HipHopListings app. If anything, it was great to go from creating my original vision to submitting my app with Apple within a month. As scary and challenging as it felt at times, I felt I had created something tangible that I could launch, validate, learn from and build on!

Fig. 1 – My design for a “Shows” to enable users to easily find out about upcoming shows and go to ticket sites

Fig. 2 – My design for a simple filtering functionality, enabling users to only look at shows in their area or by date

Hearing Charles Arthur, Technology Editor with The Guardian, talk about a “price umbrella” intrigued me. He mentioned these two words in relation to the launch of the iPad Mini and I wondered how a price umbrella works. This is what I’ve since learnt:

Price umbrella – This term refers to the pricing effect typically created by a market leader. As long as competitors set their price for a similar product within the ‘umbrella’, i.e. at or below the price set by the market leader, they will be able to compete within a specific market space. In other words, by setting high prices, a company can leave room for competitors to come in and compete at a lower price point.

How to avoid a price umbrella – Ryan Jones has done a really helpful analysis of 3 common steps involved in avoiding the creation of a price umbrella: (1) create a new, cheaper product line (2) keep selling old hardware and (3) get someone else to subsidise the product. Offering different versions of the same product is probably the most obvious way of eliminating or at least lowering the price umbrella.

Apple’s iPad Mini and the price umbrella – In his blog post, Ryan Jones has visualised Apple’s approach to avoiding a pricing umbrella very neatly (see Fig. 1 below). This graph illustrates perfectly how different versions of Apple’s devices (at different price points and with slight variations in product specification) help in lowering the price point, making it much harder for competitors to enter the market. However, with the iPad Mini currently priced at £269, there’s enough room for similar tablets to compete in the market; enter Google’s Nexus 7, Barnes & Noble’s Nook Simple Touch, Amazon’s Kindle Paperwhite and others.

Main learning point: I now know what a price umbrella is and how companies can leave precious market space for competitors to enter if they’re not careful. Even a dominant force like Apple is not exonerated from this pricing effect as is currently demonstrated by its iPad Mini. However, companies like Apple have become extremely good at continuously innovating and introducing new product versions at lower price points.