Zero states are the messages that our apps tell us when we haven’t made anything yet, our lists are done, our notifications are all read, or when our searches have no results. As app designers, we often focus on giving the user what they needed so we don’t talk much about what happens when there is nothing to give. And nothing isn’t a bad place to be.
BambooHR does a great job telling you that zero is good
Don’t get hung up on showing nothing to your users. Some apps should always give something (think searching on Amazon on Google), others should be more responsible and stop showing things (endless social media and YouTube videos) but most of the time users want to know that they’ve ACCOMPLISHED getting to nothing! This can be super important part of their workflow.
So the next time you’re designing an interface that can have “one or more” somethings show up, take a step back and consider what you’d like to communicate to your users if there aren’t any to show. It could be a good time to relax and let your hair down with something funny, congratulate your users, ask them to create, or point them to another aspect of the app that needs their attention. You should never leave someone wondering, “huh, so I guess there aren’t any then?”
I avoided reading this article for 19 days! It came to me via email and I skipped over it every day to read all the adjacent messages, but not this one. It’s not that I didn’t have time, or that I wasn’t interested. I was actually very interested to hear from Jared Spool on the subject of Jobs to Be Done. I just didn’t want to watch him tear it down! I really like Jared and I really like JTBD and I need these two things two agreeably exist in my universe. JTBD has been a catalyst for my company to successfully focus on the appropriate aspects of our customers. It’s a watchword and a sentinel that continues to guard us from wasting time on well-intentioned but ill-equipped initiatives. When is was introduced to our company we even formed a JTBD guild to justify the fervor and frequency of our acolyte-level adherence! Now, we’ve cooled since then, having found an equilibrium where JTBD is a component of our overall research and decision-making processes. But it remains a key part of what we do. And the idea of unseating it was, let’s say, “unappealing!”
But today I read it. And Spool’s article wasn’t bad. It turns out that Spool employed a good old-fashioned marketing trick to get a rise out of me before I read it, and it worked. While the article title is polemic and seemingly critical of JTBD, I don’t think he’s really against JTBD theory or what Clayton Christensen was positing. But he does make two key points (that I do agree with) that bear repeating:
How people understand JTBD now has more to do with the diversity of application from niche thought leaders and consultants, and it’s getting messy.
JTBD isn’t groundbreaking for those of us who’ve been in user design for a while.
I’ll point out that if you want to prop up JTBD as a be-all, end-all for your business, you’ll find it lacking. It was never meant to be comprehensive. Christensen admits that and doesn’t explore, in particular, appropriate methods of user research. There is already so much content being created to apply the theory to different kinds of businesses. There will be different schools of though because there is room in business for it. As a theory, and a principle in practice, it’s up to you to determine how JTBD should be applied in your company. But as a tool to help form proper processes across the disciplines of your company, I think that JTBD is essential. Competing Against Luck should be on the recommended reading list for anyone who has honest doubts about their ability to correctly read human-driven markets. The article from Spool is also a good read. In particular the links to other works on design research.
Directed Discovery + Jobs to Be Done + Minimum Viable Product + Agile = Your business has a chance
If you aren’t 100% sure that you understand JTBD, you should read up. It’s well worth your time. But don’t start with derivative work or consultant websites. Read it directly from Clay. …… You’ll quickly understand what it’s about, and what it isn’t about. And then it’s up to you to determine how it fits in your company and processes. For me, JTBD plugs in after Directed Discovery and before MVP. Take that, Spool! 😀
I read an article on Quartz by Karen Weese this morning that helped me reflect on society’s biases—as well as my own—around how people react with such a range of behaviors and whether that is primarily caused by the individuals themselves or their circumstances. In short, the idea is that when people behave differently than we would, it is not the individual that we should be skeptical of, but their context. I remain hopeful in mankind and I try to find opportunities to explain irrational behavior in terms that don’t condemn. Behavioral economics supports me in this and it drives us to better understand, and even predict behavior based on the things we can understand: context. Two applications from the article are noteworthy. In particular the second applies to my profession directly.
Poverty’s inherent lack of resources and time significantly but temporarily diminishes intelligence, making it hard for just about anyone to thrive. Skeptical? Read the article. Poverty is hard.
Job and situational stresses (particularly WWII bomber pilots) reduce mental bandwidth, which makes it hard to reliably execute even common tasks. In creating software for higher education classrooms, this means that we need to remember that our users aren’t focusing on us, the tool, but on their assignments. We can’t expect everyone to read and explore and emotionally invest in what we build because they’re already invested in other things. Know your place.
It’s too easy to write people off and explain away their failures or our differences on intelligence, race, political party or gender. Anyone can do that. If you want to talk about intelligence and diversity, invest actual time yourself in understanding where people are coming from and how little they may need to care about what you care about. As Dietrich Bonhoeffer said, “we must learn to regard people less in the light of what they do or omit to do, and more in the light of what they suffer.”
I’ve enjoyed listening to the Startup Podcast over the past couple of weeks. It’s encouraging to listen in on seemingly normal guys as they put together a brand new company. In episode #13 they talk about rapid design prototyping with Google Venture’s design team. The team walks them through a design sprint to discover what their mobile app should be.
Fake it ’till you make it… or don’t.
In Gimlet’s case they should not build a mobile app, and I can’t tell you how many months of development time I’ve saved by NOT BUILDING an idea that we’ve had. In a relatively short amount of time you can design out a website or app and see if it’s going to really meet your needs or if it’s just a cute idea. The world is full of cute ideas – I don’t want those. I want a great idea that can work.
Save yourself some time, developer. Don’t build it until you’ve seen it.
