in an election year where either party’s candidate seems absurd depending on which side you’re on, it’s easy to focus on the best choice in 2016. yet, i view this election as merely the local maximum, to use a design term, instead of the kind of candidate we need, desperately.

a few notes before i get started…

i don’t closely follow news or politics, but i’m guessing i do so more than most of the country.

i’ve supported candidates on both sides and generally disregard the impact of the president. not much seems to change regardless of who is in power. it’s hard to turn the ship very much.

i’ve largely voted 3rd party all my life (not that it mattered much since i’ve lived in texas, new york, and california -- states that are called red or blue the moment polls close).

parties frustrate me since policies are fluid. inevitably the sitting president ends up taking a position the used to belong to the other side. e.g. didn’t republicans used to like free trade before trump showed up? e.g. didn’t democrats like to support civil liberties before snowden showed up under obama’s watch?

with that said, a few assumptions that i’m working under…

the economy has changed dramatically. pandering to factory workers is a waste of time.

education is broken. school is not the answer to economic equality or advancement.

government's sole duty is to unburden its citizens and open opportunities.

so, my ideal candidate for president, which could easily come from either party at this point…

someone who is loathe to protect dying industries. the state of new york, for example, just banned airbnb. how is any major party’s candidate not against this? there is no better example of the internet disrupting the old, which will lead to productivity and economic gains, but the government is getting in the way. either party could and should own the platform of internet disruption and opportunity.

someone who doesn’t add to the debt. whether or not the united states should be a hegemon is up for debate. the structure of tax policy is up for debate. how we address entitlements is up for debate. what should not be up for debate is spending (whether on wars or governmental programs) that put america deeper in debt.

someone who moves our collective thinking forward. i can’t believe it’s 2016 and abortion or gay rights is an issue that matters to people. democrats are about civil liberties. republicans are about the government staying out of personal business. how are we all not on the same page of getting antiquated issues out of the debate?

someone who can see issues in multiple dimensions. for example, immigration is not simply about national security. for me, it’s largely an economic issue and a way to move the country forward. the fact is america is still where the best and brightest want to live and work. i don’t care if you’re a dishwasher or software engineer, you should be able to come to this country to work if you want.

finally, someone who doesn’t pander to fear but moves our country forward. borders, lines, and alliances have never been more fluid. both state lines and international, the internet is changing everything. the only way america competes is by embracing our biggest competitive advantage -- the fact that everyone wants to do business here. from fundraising to legalities, the united states is still where everyone wants to live, invest, and vote.

here’s to a fun election day… and a better one to follow hopefully not too many cycles down the road.


Authorjonathan hegranes

from startups weeks old to (at least once) public behemoths, it’s remarkable how often companies fight how their customers view them with who they aspire to be.  regardless of how much users value parts or pieces of their business, companies routinely miss their true calling.

i’ve both witnessed and worked for these companies, and it’s often the pieces of a company that are deemed valueless that in hindsight are bigger opportunities than that which the company hoped to conquer.

when i worked at world poker tour, management was thinking about being the super bowl of poker in a television-centric world, all the while millions of people were rabidly playing our free poker game.  it seemed silly that so many players cared about fake chips, at least until zynga came along.

blackberry was similar.  while it struggled to figure out how to build a phone without a physical keyboard, it ignored the messaging network and community that it had built.  last decade, i certainly was not alone in buying blackberries for its messenger app.  in a world of whatsapp and wechat, it’s crazy how they ignored the potential of messaging, choosing instead to battle on hardware.

fitbit is in the midst of making this same mistake.  they are ignoring the community of fans that love their app and community, but have moved beyond their hardware.  if only fitbit would realize that they build a) the world’s best alarm clock and b) step tracking software people would pay for.  this continues to be the most obvious short in the market today.

now apple is promoting itself as a services company.  it doesn’t matter what they tell themselves.  investors and consumer will decide for themselves.  perhaps more interesting are companies like disqus which are finally starting to execute on how consumers view them and what they want from them.

as i build products, this is one of the most important things i think about.  the other is thinking about the user flow (what were they doing before using my product and what will they do after), but i’ll save that for another post :)

Authorjonathan hegranes

mobile has moved well beyond a simple tap or drag.  call it the tinder-ization of mobile, but users now routinely gesture, swipe, flick, pull, drag, long press, and hard press.  the more i delve into building mobile apps, the more i notice the finer points of how these features are and can be implemented.

there’s nothing quite as telling as handing someone a new build of an app i just completed and see what they expect to interact act with and how.  from these interactions, plus being an avid downloader of apps, the one constant i’ve noticed is how there is no ‘rule of thumb’ for gestures.  some email clients archive by swiping left.  others by swiping right.

routinely apps will go so far as to build in tutorials of how and why you should swipe.  i’ll expound upon more examples and ideas throughout this post, but i’ll begin with this -- the basis for how i’ve come to think about mobile gestures.

where web navigation is directional,

mobile gestures are relational.

if you want to go to the bottom of a web page from a computer, you scroll your mouse downwardly or peck away at the down key.  but if you’re on your phone and want to go to the bottom of the article, you swipe up.  moving away the content you’ve read and pulling up the new content into view.

if you want to view the next photo in your scroll, you swipe the current photo out of the way to reveal the next photo. 

if you want to view a menu or some sub action, you move an existing view out of the way or drag in a new view.

this primary difference with mobile is virtually opposite to previous web-era user experience design, but it’s also more natural.  watch a baby play with a phone, and they get it.  how your fingers interacts with glass on a screen is almost innate.  so as mobile developers and product people, how do we design for the best (defined as logical + magical) experience?

short answer: follow tinder (which is also how apple defines gestures), don’t buck convention, and pay close attention to context.  

a quick definition before we continue: swiping right means moving your finger from left to right.  if the focus of the interaction is visible, the object should move and/or dismiss to the right.  thinking swiping away a card on google now, or dismissing a swarm message after your last check in.

but if the focus of the interaction is not visible, new content should appear from the left.  think scrolling through photos, or moving to the next day or week in your calendar.

getting the right direction of a gesture was something i struggled with during the latest update to airbear.  i wanted to make it easy to move between different days, especially since this is where monetization kicked in.

the airbear feeding home screen

i had different implementations on my phone, showed people to see which way they would expect to swipe, and received ranging reviews.  most said it didn’t matter, that they’d learn which way to swipe.  throw on top my natural inclinations towards backwardness as a lefty, and i was stumped.  

so after shipping what i now consider that wrong implementation, i started studying gestures.  i want to build more in my apps, but i also don’t want users to have to learn something new or worse be confused.  as intercom recently published about some of their user testing, they were seeing users swipe left to dismiss (largely because of tinder habits).  even google gets things mixed up, as it tries to buck this swipe left to dismiss convention.

really? swipe right?!?

best practices for winning at mobile gestures

1) context -- does the user have a natural sense that an element is swipable?

without a nudge (or ugly tutorial) a user won’t know that some nuanced element of your ui will register a gesture without being primed.  table views do this by default (such as text or email).  movement that presents the element can also accomplish this, as well as also giving a glimpse of further content (such as a new screen or subview blurred by the layer on top).  arguably the only time a tutorial is acceptable is when the ui is so simple that an app needs to orient its users with all of the features that are invisible, discoverable only with swipes, such as what clima -- my favorite weather app -- does.

2) direction -- which way(s) should a gesture be received?

follow convention (tinder and relational as discussed above), but don’t limit the ways in which a gesture can work.  e.g. twitter only lets you dismiss an image vertically, whereas slack recognizes any gesture direction and then pleasantly spins the image out of view.

3) multi-function -- are there options other than gestures?

while users acclimate themselves to expect more gestures, build in other ways for users to interact with your product.  sure a gesture might be the best way to move between days in airbear, but the user can still tap on the individual days to move directly.

4) bespoke magic -- can you implement a common gesture in a new way that speaks to your product?  can you move gestures beyond navigation?

especially as long and hard presses become more expected, delight your users with some magic that speaks to your product.  robinhood did this by having users confirm a trade by swiping up.  facebook messenger did this by having the size of your ‘like’ determined by how long you hold the like button.


in the end, we’re still in the very early days of mobile ux and gestures.  guessing most people don’t use them to their potential or realize how ubiquitous they really are.  as a side experiment to this post, i’m running a poll to see how many people use gestures on their notifications.

Authorjonathan hegranes

the perfect product balance makes the user both love and hate the experience.  the love comes the way the product solves the user’s problem and the way it makes them feel in the process.  the hate stems from the love, because by loving the product so much the user wishes it did even more.  any place in between is product ambivalence -- a no man’s land where projects and companies die.

perfect product pacing starts by solving a clear problem and shipping a simple first version of the product, only moving on and building more when the love and hate are sufficient and growing.  you start by having a meaningful first product, but as as reid hoffman, co-founder of linkedin and now vc at greylock, says, “if you’re not embarrassed by your first version, you’ve waited too long.”

too often an inexperienced founder will hesitate and struggle to get that alpha or beta out the door because they are tuning and building in fear that the current version isn’t polished or doesn’t do enough.  even experienced but undisciplined product managers will make this mistake, bolting on too many features without justification.  the key is to have an early thesis of why specific users want what you’re building and set out to prove this with as little code, development, employees, and cash as possible.  

this is the tact i took with airbear.  for sure early brainstorming and mocks crept towards a bulky v1 product, but i ultimately got it down to providing one clear value prop -- simple breastfeeding logging that lets parents know how that day’s feedings are going.  users noticed this and responded.

over 10,000 feedings later, positive reviews, and lots of love were also met with plenty of criticism.  what about bottle feeding?  why can’t i see the history?  seeing x or y data would be useful? can you add alerts?  this level of hate and wanting more not only showed me that there was an audience for airbear, but also showed me what i should work on next.  

you know you’re on track when you get angry feedback because that never comes from ambivalent users

arguably the greatest value this diligent method of product pacing provides is not having to go back and rework or delete old, stale features.  probably half of my day job these days is stripping out old features or irrelevant functionality that was built too soon and without justification.  des traynor, co-founder at intercom gives a great talk that compares two products.  one is a simple product that sees its competitor with tons of features and thinks ‘we need to add those’.  meanwhile that bloated product sees the simple one and thinks ‘i wish we didn’t have all these features, which are hard to maintain or that no one uses’.  

beware of product envy and build only when the time is right and the love and hate buckets are overflowing.  some of the best products today did that, even with millions of venture capital in the bank.  nothing shows prudent product pacing quite like the time between launch your iphone app and android.

if people love your product, after around the first few dozens of users you will start hearing requests for android.  these four companies clearly had the love factor, but they still waited on average for almost a year and a half to launch on android (and you can be sure that a lot of hate was piling up during that time).  if you’re curious how other great companies progressed and paced, there’s a cool site that lets you explore their timelines in more detail --

part of being a release note connoisseur means i also spend a lot of time looking through version history.  how, why, and when app updates are pushed tells a lot.  granted big mega corps like facebook or twitter are on a bi-weekly cadence of ‘minor improvement’ updates, but the early days of an app show the most drama.  big new features come out after a quarter or two of listening and talking with customers.  these can be the hardest months as it’s easy to just want to keep shipping new stuff.  but it’s when you have hundreds of users (as opposed to millions or billions) that you have the freedom to both wait and be bold.  

code cleanup and performance stuff aside, resist the temptation to ship new stuff. wait to see not just how many people are using your product but also how they are using it (which could surprise you), and by all means focus on growth.  that’s the road i’ve been on since launching airbear in february, and i’m excited to announce a long awaited update in the itunes app store.  

with the last airbear update, we are now just at step #2.  if we’re going to get to step #3, that’s going to take even more hard decisions about product pacing.  they may have the same number of wheels, but a bicycle is far more complex with far greater potential.

what step is your product on?

Authorjonathan hegranes

users can both feel how much care you put into a product, and how much care you didn't put into it.  this is often why big companies can't win because they have to scale.  or at least they think they do.

actually doing things that don't scale is difficult in practice, but your users will notice the difference and feel the love you put in and the time you took to make everything just so.  a great example of this is acompli versus inbox, wherein you have a small startup trying to make a great email app and inbox, which is google's latest email evolution.

i'm actually a fan of inbox and use it for my personal email on my laptop.  lovely animations combined with easy navigation make it wonderful, except that google refuses to do things that don't scale.  

in a day where i took both an uber and lyft, google inbox has put these in different buckets.  you'd think they would take the top 50 or 500 apps vendors and create specific rules for them.  manual, yes.  tedious, a little.  but perfect.  your email app, especially google, should know the top 100 finance companies, top 100 travel companies, etc, etc.  if you want to algorithm results after that, fine, but get the fat part of the curve exactly right.

meanwhile acompli has a better 'focused' inbox than google's priority inbox.  it recognizes actual people better, while also pushing aside newsletter type stuff that truly isn't priority.  just guessing, but i'm assuming a lot of this was done through very inefficient means.  at least at first, while they were ramping up.

the result was microsoft bought acompli for $200 million, and to microsoft's credit did not undo the magic.  they kept it open, kept it beautiful, and didn't make it too outlooky.  i'm still getting used to having outlook on my phone, as i hadn't used it for a decade, but it's still the best email/calendar option i've found on the iphone.  i just hope they keep putting the same care into the product.


Authorjonathan hegranes

six months ago i became a dad.

six months ago i started coding.

today i’m announcing air bear! 

you can read all about air bear on our medium post 'babies are hard' about how we’re helping new parents with feedings and providing a little sanity along the way.  or just go straight away to download the app :) 

 this is a story of how air bear came to be.

going back to last summer, apple had just announced swift, my friend dorian was starting a #codeaday challenge, and my wife was about to give birth to our baby girl.  together, these were the beginnings of what has become air bear.

anyone will tell you that i’m a sucker for anything new (i.e. chewing new cinnamon-roll gum as i type this), so apple’s new programming language was already enticing.  swift is the heir to objective c, which had been around since the early 1980s. pretty much every app on your phone today is built on objective c, but just comparing some of the syntax and features of swift vs objective c and it’s really quite beautiful. and from my perspective (a total noob), more intuitive.

coding has never been my day job, but always something that i’ve tinkered with. i’ve taken a few ruby classes and enjoy fiddling around with different technologies, but doing the actual building was a first for me.  it’s a skill i wanted to start developing for a number of reasons, as it helps me think about and understand products at a much deeper level, but it’s also a necessary skill if you actually want to be able to implement ideas on your own schedule.  as @fakegrimlock says, ‘if you not code, you not understand code’.

from "how to startup" v0.5 by fakegrimlock

figured i better get harper learning git at an early age.

figured i better get harper learning git at an early age.

so between swift and dorian, my brain was in the right space. harper -- our daughter -- was the inspiration.

one of my favorite posts by paul graham is ‘how to get startup ideas', where he says to work on a problem you have, and my problem at the time was the freshly minted baby that would wake up every few hours to eat.

we had taken baby classes, read books, etc, etc, but as this was our first kid, we didn’t know what to expect and i quickly noticed some repeating themes.  there was the question we’d ask 10x a day -- “is it time to feed the baby?” and that was topped by the number of times we’d wonder -- “is this normal???”.

naturally i looked to the app store for help.  

while there is invariably an app for everything... there is rarely a good app for anything.  

i pretty much refuse to use an app that doesn’t look good, especially the icon.  with existing baby apps, i had to throw that rule out the door right away.  while a lot of tracking and logging apps are functional, they are not easy to use, and certainly not fun to use.

so wishing i had a better way to know if our baby was eating well and when the next feeding was coming next, i set out to build air bear.

the first few months were all about learning.  learning what is a good feeding schedule.  learning what parents need and want.  and learning how i might actually build this thing.

after talking to a lot of parents, observing what hacks and systems my wife came up with, and armed with some base development skills -- it was finally time to start building.

making something simple is not easy, and the air bear concept had already ballooned into too much.  so the first step was narrowing down what air bear would be.  initial thinking was to track feedings, bottles, diapers, health stuff, and maybe even memories.  we may get there over time, but we needed a place to start and feedings are the most important.  it’s the thing mom’s track the longest and care about.  frankly something they’ll care about forever.  

but even after deciding to *just* start with feedings, i still ended up writing and later deleting more code than i needed.  i thought about collecting the birthday or birth stats like weight and height, which are useful but not totally necessary.  after distilling further and further to the root problem i wanted to solve, i got down to a what i think is a beautiful and simple minimum viable product.

i love this tweet by @manicho about a good mvp and hopefully air bear is closer to the second row than the first --

so this version of air bear in the app store today is the skateboard you see at stage one.  and what stage two will be is still to be decided.  i have a lot of ideas of stuff i want to build and new features i want to incorporate, but i’ll largely be looking for feedback from early air bear users.  what they love, what they hate, and what they want to see next.

please go download air bear on the app store today .

     (    while you’re at it, please give us a 5-star review :)


(while you’re at it, please give us a 5-star review :)

and if you know of any new parents or those that are expecting, please do introduce them to air bear.  i’d love to hear their thoughts and feedback.  leave a comment below, or shoot me an email <> any time if you have any ideas for the app, for parents, for anything.

lastly, so many people to thank.  my wife has been amazing and supportive as i asked her *lots* of questions about breastfeeding, and super patient while i spent early mornings and late nights working on air bear for the last few months, especially when i was grumpy because there was some damned bug that i couldn’t yet figure out.  aaron who as been great to work with, kept me in check, and who designed the amazing air bear logo!  throughout the process, lots of friends have been awesome with feedback, support, and making really cool introductions to fellow new parents who might want to use the app, or to baby and lactation experts that have shared their wisdom into what nursing moms need to hear.  thank you <3

and there's also been so many amazing technical resources (besides stackoverflow) and experienced people that have helped along the way.  just a few of my favorite new people -- whether they know it or not -- are

@jonkawa, who provided some unique wisdom along the way.

@mengto, who is a design and animation magician.

@jamztang, who writes killer stuff on ios.

 & @awolnation, which has become my favorite early morning coding music.

Authorjonathan hegranes