In my Log In post I was hoping that One day, smarter Log In pages would be able to Trust my location. A mere 2 days later, Google announces Smart Lock (as part of Google Play Services 6.5 and Lollipop).
The Verge provides a good translation of what this will mean to regular users.
In a nutshell, you can now define a location as safe, and then your Lollipop phone won’t ask you to unlock it when you’re nearby—it’ll just let you straight in.
As a team leader, I sometimes find myself in a situation where I have to communicate a decision to my team. Here are some key principles that I a guide myself by when I do this.
Timing is one of the most important things to me. If my team find out about the “news” from somewhere else, their trust in me is likely to be shaken. I am there to look after them and to be their voice in the conversations that have an impact on them. The sooner I can do that, the more I can help them.
At the beginning of the discussion I try to clarify what I will talk about. This provides not just structure, but it may prevent questions that would be answered anyway. At the same time, it enables everyone to write down any questions that I may have overlooked in my FAQ.
Ideally, the agenda should be sent with the meeting invite, but sometimes this is just not possible.
The reality is that not everyone reads their emails. If these emails contain business speak, are too lengthy, or come from a source that is too far away in the organisation, then it’s possible that people will just skim the message and not retain too much information.
The first part of the discussion should definitely include a quick recap of what has been going on, to bring everyone up to speed.
I have seen so many people try to become somebody they are not during a presentation. Their pitch or tone would change. Their body language would be awkward. Their hand gestures would be unnatural. I try my hardest not to be one of these people.
Be yourself. Everyone else is taken.
I feel like being genuine helps reassure people that I am being honest. Even if the point of the meeting is to “sell” to the team something that they might not be too happy about, it’s still important that my tone is affiliative.
One very important aspect is finding the right balance between getting lost in the details (overwhelming the team with too much information) and being too vague about what the decision really entails.
I try to think ahead of the questions that the team might have. Putting myself in their shoes is good for several reasons:
I am a strong believer in the power of an honest “I don’t know”. Realistically, if the truth is that I don’t know, then anything else I would say is BS. I respect my team too much to reply with a political, or vague answer. It’s also very likely that the answer will be important to me too.
When closing, it’s important to remind people that the communication channel is still open. Some people are introverts, or simply not comfortable asking questions in front of their peers. Others prefer to communicate in writing. Their voices are equally important therefore they need to know that they can follow-up with me.
Hooked: How to Build Habit-Forming Products
I just finished reading this book by Nir Eyal. I strongly recommend it to anyone who wants to learn about building addictive products.
In a previous post I was talking about the log out experience, and the contents and functionality that I think should be included on the Logged Out page. Today I will tackle the Log In page (if you really must have one).
If you must enforce the use of an account then this should happen as painlessly as possible. Both you and the user are probably in agreement that this step is required only because we haven’t yet come up with a simpler way to establish this trust relationship. Further down, you can find a few suggestions on what may become, one day, a more seamless authentication pattern.
The authentication & authorisation topic is large. In a nutshell, identity verification takes into account three factors:
In this post I will only discuss the first point above. Even when I include items from points 2 and 3, I will do so with the intention of making point 1 simpler, rather than to increase the security of the authentication mechanism. In this post I’d like to stick to making things easier, rather than more secure.
The Log In page must have a few basic ingredients:
On top of the the above items, there are a few more ingredients that can help make the log in experience more painless:
Twitter’s Log In page is minimalistic
Mix all the must have ingredients above, add your preferred nice to have items and you should get a pretty decent log in form. Rather than me drawing up a log in form, I chose to complete the picture and include the log in forms for the sites I mentioned in the Log Out post.
Facebook is not confused; it’s on a mission
Notice how Facebook almost gives more priority to the Sign Up process. That is probably tied into their drive to get more users onto the platform (warning: pure speculation). The other very interesting thing about Facebook’s Log In page is just how similar it is to their Logged Out page. Can you spot the difference?
For some inspiration, have a look at this set of Mobile Log In pages.
Here are a few suggestions on how authentication could, one day, be simpler.
If I Log In from the a certain location (IP / WiFi / etc), there are no other people using the site, I always use the same browser, etc then maybe you can “assume” it’s me. Maybe you can prompt me to allow you to make that assumption?
To my phone. If my mobile device has just started using the same public IP, or is in the proximity of the device that I am trying to Log In from, you can probably “assume” it’s me. If you want to be sure, maybe you can build support for Handoff / Continuity in your site and trust my mobile device to do the authentication.
What if there was an app on my computer that I could start and I could say: “log me in to Facebook”? This app could check my voice, unlock my keychain, extract the credentials, start a browser/tab and fill in the form for me.
20% of Apps are only opened once, improving from 26% four years ago.
So how is your onboarding experience?
Your user has logged out (Signed Off, Logged Off, Signed Out, etc). What happens next?
Many online experiences end there. I believe that to be a missed opportunity. The page that gets displayed to the user as a result of logging out is an integral part of the online experience that your site provides.
Why has the user logged out?
A few reasons spring to mind:
1. they want to switch accounts
2. they’ve been inactive for too long and the system logged them out
3. they have finished using the site and they use a shared computer
These are just three possible reasons, but they are probably enough to draw some quick conclusions about what a good log out page may contain.
What should the logged out page be?
Regardless of the reason why the log out took place, the user should be shown a confirmation message. They need to know that their wish was granted, or that they have been logged out for some other reasons (such as their inactivity).
Facebook invites the user to “stay connected”
Twitter asks the user to get the apps
Reasons 1 and 2 above virtually require that a log in form be present on the page.
Reasons 2 and 3 can be regarded as an opportunity for reaching out to the user with an invitation to continue their interaction with your site through a more personal channel, a channel that is secure and omnipresent: the user’s mobile device!
Why not remind the user about your mobile app, or your mobile website. Tell them to take you with them by installing your app. Better still: make the most of features such as Continuity to allow the user to continue their session on their mobile device.
The rest of the content that should go on this logged out page is not so obvious. It’s not just a matter of taste, it’s also a matter of personality. You can consider the user disengaged and show them an ad. Or you may take this opportunity to strengthen your brand. You may even go all melodramatic and put a “sorry to see you go; please come back soon” message.
Whatever you decide to do, just try and think of this page as an integral part of your product. Don’t think of it as the end of the line and you may end up building an avenue for increasing engagement and retention.
This topic has been covered time and time again. Typically, these articles cover a mix of technology, performance, ROI, look and feel, and other such metrics.
Today I’m going to suggest that the end user’s ownership of an app (as opposed to a website) is one criteria that businesses should consider when making the decision to build a Native App. I’m also proposing that building a Responsive Website is no longer an option, but an expectation.
In 2014, even the cheapest smartphones come with HTML5 capable browsers! End users do not and should not have to understand why a website is different, and sometimes even feels alien, when viewed on a mobile device. The time when we had to compromise on mobile because of technical reasons is long gone. Let’s leave this here.
If the mobile browsing experience is in the same class as the browser experience then why should you even consider an app?
Unless you’re planning to build an amazing app that you plan to support long term, keep up to date with the fast evolving mobile UI/UX, in which you utilise the mobile platform paradigms to the point that the user feels like it was built in collaboration with the designers of the first party apps, then you probably shouldn’t build an app.
The subtlety here is that it all boils down to the fact that you own your website, but the end user owns your app.
If the user has a bad experience on your site, they can’t get rid of your mobile optimised (hopefully responsive) website. Your links will always work, even if they remove all shortcuts or bookmarks. A short url, a web search result or an ad will always be able to bring them back. When they’re back you’ll have a chance to make them change their mind and convince them to return in the future.
On the other hand, if the user has a bad experience with your app, they can simply forget the app ever existed on their device. They will delete it and they’ll do that almost as a punishment for your failure to delight them. Deleting the app will close all the communication channels once provided by that medium: all extensions and widgets will be gone, all URL schemes will seize to function. The reality is your app is competing with potential photos of their friends and family, or with another app that is more in fashion than yours.
The end user owns your app because they install it, they dedicate disk space to it, and they can get rid of it if they choose to. They are in complete control of this lifecycle and, you may not realise this, this lifecycle has financial and psychological implications.
Unlike accessing your website, when installing your app the user is likely to be asked for their password (or fingerprint for Touch ID). Even if your app is free, the psychological connection is made: they acquired your app. They are now using disk space just to have your app around.
Your app must be delightful, it must add value every time it’s used, otherwise the user will eventually run out of patience and delete it. Once they do, you will face a big uphill battle to convince them to give your app another try.
There is no such psychological attachment to your website because the user is not involved in the site’s lifecycle. They usually just “ask” a search engine for it. When they run out of space for their next photo they won’t think which sites they can remove…
If you can’t build a delightful mobile app, then you’d better have an amazing responsive website. The reality is though, that if you don’t have both, then it’s likely that you’ll never be the first port of call for a mobile user.
The Product Roadmap is like the north star. The same way a sail boat is guided by a trustworthy, never changing light source, the Product Roadmap is there to give a team direction and comfort that they are moving in the right direction.
The goal is to get the team to be intrinsically motivated about the Product Roadmap. I’m making the assumption that if you’re reading this post you probably agree that selling a roadmap to the development team is a difficult undertaking.
In order to be able to provide direction and comfort, the Roadmap has to have the team’s buy in. In the remainder of this post I will describe the way I believe a team should be approaching the definition of a successful Roadmap.
The teams are made of a number of skills. Some teams can have just two tiers (or just one when the leadership is provided from whithin the team) while in larger organisations there can even be a structure such as the one below.
| Product Manager | Ultimately responsible with the delivery of the product |
| Technical Lead | The technical go to person for the entire team (cross skill) |
| Team Leader | Responsible with the entirety of a skill (e.g. developers) |
| Team Member | BA, Designer, Developer, Tester, etc |
In reality, the more tiers there are in a team the higher the risk that there will be voices that have not been heard or that certain individuals will end up not feeling represented. Later in the life of the product these are most likely to become the least motivated or the least engaged team members.
I believe that people’s motivation disappears when the Roadmap is enforced top down. Too much energy has to be spent on selling a roadmap epic as opposed to discussion the merit of that roadmap entry.
Instead, I suggest a bottom-up approach. I call this, the Pyramid of Trust. I will describe how this works by looking at a complex team structure. In a simpler situation, pyramid levels could simply be removed.
The Pyramid of Trust … is built from the ground up
Everyone takes part in this exercise. Allocate enough time to allow people to collect ideas and to have a couple of minutes to pitch them. There are no bad ideas at this point. Think of it almost as a brainstorming phase.
This first step is also the most important one, because this is where trust starts being built. Here are some guidelines on how to approach it:
Realistically there will be many ideas that the team simply won’t have time to build. Some ideas might just be plain bad. Other ideas might need resources that simply are not available. These are just a few reasons why in step two, the Team Leaders should get together with the Technical Lead and the Product Manager to:
Delegating or sharing this responsibility with the Team Leaders is beneficial because:
It’s time for the Technical Lead and the Product Manager to make the final selection for the Epics that will make it into the Roadmap.
This is the step where emotion is put aside and the business and the technical skills get together to figure out the best ways forward. At the end of this step the Product Manager will have mandate from the development team to pitch a Roadmap to the business.
The Technical Lead will need to figure out ways to plug the holes in the team’s skills set, resource and prioritise appropriately, find training and upscaling opportunities. All these will help the team be as prepared as they can be when they come about implementing this Roadmap.
The Product Manager is now under pressure from the team to represent their ideas when pitching this Roadmap to the wider business or to the stakeholders. Compromises usually need to be made and not everything will work according to “plan”. The bright side to this approach though is that the Product Manager will have the confidence to speak on behalf of the team knowing that if their suggestions make it into the agreed Roadmap then the team are likely to be motivated and engaged as they are, in fact, co-owners of this Roadmap.
It’s important to remember that if an idea that was generated by a team member makes it into the final roadmap, this person should be involved in the phases to follow: exploration, research, strategy, implementation. This way credit is given where it’s due, the sense of ownership and belonging is reinforced and this becomes a good example for the roadmap sessions that will take place in the future…
A good idea would be to make the roadmap as visible as possible, in a way that does not use actual dates. The focus should be on sequence more than anything. I would suggest three monthly updates on progress. These would also serve as reminders of the common team purpose.
I need to put myself out there again. I am at crossroads with my career and I am hoping that writing about the decision making process and the context around it all will help me make the right decisions.
Instead of spending a lot of time and energy writing about my entire life, I will quickly summarise the last decade. Realistically, the last five years are the only relevant ones, so I will go into more detail as I approach current day.
About five years ago (2009), I was wrapping up my gig with Fronde Anywhere (a Mobile Banking & Finance pseudo-Start Up). I worked there between 2005 and 2009. My “consultant” title seemed to be the only generic term that could encapsulate all the roles I performed:
I soon realised that building software was just one facet of my technology persona. I also became aware that becoming involved with other businesses, and taking more product ownership was what I really wanted to do. Simply put, my view of my career and my priorities was somewhere along these lines:
The company I was working for was a good, comfortable place. However the challenges and the opportunities were not there so I had to make some changes. Without doubt, the most drastic change was starting Tmro. That was possible once I decided to reduce my work week from five to four days. I’ll dissect Tmro some other time, though…
The other change that I made was to take a job at Trade Me (2009). I joined as a back-end developer, but at every occasion I was pushing the Mobile agenda. My .NET adventure was short lived. The contractor that had been hired to build an iPhone app was constantly asking for my support which was formalised within a few months. His contract wrapped up and I became the solo developer. We released the first version of the Trade Me for iPhone app sometime around Guy Fawkes (2010).
The iPhone app grew fast; so fast that within just a few months the Trade Me Mobile Team was formed, when Sam joined me as the Mobile Team Tester. Design was a separate entity altogether (It took a few years until the designers joined the developers and the testers to form cross skilled squads/teams as part of the larger Mobile Tribe/Team). The Mobile Team expansion continued by hiring two more iOS developers. We agreed to keep the developer to tester ratio as close as possible to 3 to 1. Before we knew it, we were investigating the possibility of building an Android app to repeat the success of the iPhone app. We did it ourselves, while building another two apps for a satellite business. With four apps to support we finally hired our own Mobile designer. This happened just in time for the first vertical app: the Trade Me Property for iOS app and the beginning of our bravest app: the Trade Me for iPad app. Things escalated quickly: in just a couple of years the app portfolio was growing. So was the team. What was shrinking was the time I was spending building solutions. I found myself doing more and more product advocacy (breaking business rules for the sake of making the apps better), arguing for resources, writing project plans and proposals, taking part in strategy meetings, and most importantly, managing people. The dream was coming true: my medium and long term plans were going great.
I did not anticipate was was about to happen next, but in hindsight it’s easy to understand how building a product suite, growing and managing an entire team, and representing these both internally and externally was going to transform me into a Product person. My job title said “Team Leader” but, in my heart, I saw myself as a Product Gatekeeper with a clear understanding that keeping the team happy was the first step towards delivering delight to our members. My vision was thus formed:
Only a happy team can build products that people love.
Despite attending WWDC (twice), Google Developer events, Rails camps, Webstock, UI/UX conferences, Agile barcamps, and more, I was quickly drifting away from being just a software developer. My attention was constantly focused on the big picture rather than just the implementation detail. Most of the energy that used to be directed at learning new programming languages and development tools, was now invested in learning about what makes people tick and how to build products that people love.
The Mobile Team is now large (approaching 30) and is made of a bunch of incredible people. There are five leaders who are amazing at representing their colleagues. Our skills cover Android, Design, iOS, Test, and Windows Phone. We have outgrown Wellington (we are building a brand new team in Auckland). I sometimes wonder whether this is the largest Mobile Team in New Zealand. The products are more than just “relevant”. Our official strategy documents require that “mobile is ingrained” in everything we do and this requirement is justified by fantastic stats. There’s a problem though: I want more. Currently, I find myself waking up in the middle of the night, taking notes and jotting down thoughts and ideas for a new Product that I have had in the back of my head for around four years now.
I probably won’t be able to talk about the details of this Product for a while. I will write about the challenges that I come across and the decisions that I plan on making starting with the next post…
You can do a number of things, too:
