You only get one chance to make a good impression.
I speak often on the difference between building an MVP (Minimum Viable Product) and what I like to call an MLP (Minimum Lovable Product).
I don’t believe in building MVPs.
I believe in making incredible product experiences. And that starts with unforgettable first-time experiences for new users.
Contrary to MVPs, where the goal is to get something barely usable out the door and into the market for initial feedback, an MLP takes the opposite approach, treating, among other things, the first-time experience of a new user very seriously.
This is the first time they’ll see your product, the first time they’ll experience who you are and everything you stand for. And if what they experience is bare bones and clunky, that’s how they’re going to remember you.
You have to earn the right to more of your users’ time.
Most startups don’t think about it that way.
Instead, they think solely about the core product features, “the value proposition” and worst of all, what their marketing strategy is going to be. How a new user experiences the first 30 seconds using that product is almost an afterthought.
Imagine if that’s the approach Apple took. Imagine if your brand new iPhone came in a worn cardboard box — instead of the pearl white vacuum chamber that feels like you’re being given a prized jewel. Or imagine if, the moment you turned on your brand new MacBook, it was out of battery. Or it couldn’t locate your local WiFi signal and easily connect to the Internet.
As a new user, you would immediately feel frustrated, upset, let down — instead of excited, joyful, or eager to start playing with the product.
If you want to build a product people love, you have to build a first-time user experience that tells an emotional story.
Let me give you an example.
When we were building Crashlytics, we discovered that the first-time experience for developer tools for mobile were abysmal. Facebook was the creme de la creme, and theirs was a long, instructional page with endless links that took 20–30 seconds to scroll down. Others had wikis with 72-steps (“Oh, you use a Mac? Click here…” 26 more steps… “Now go back and resume.”). Or even 10-minute long YouTube videos with a guy speaking in monotone voice: “Now.. drag this… here. Then… click… there.”
What an awful way to make a first impression and to start a relationship with your users!
So, we decided to fix that.
We asked, “How can we make the first time experience fun, delightful, and do something that Facebook, Google, Amazon, and others obviously couldn’t do?”
Well, we built a consumer-grade installer app. It even had an icon that *wiggled* so developers could understand it had to be dragged. This may seem like an easy (even obvious) undertaking, but to create an installer that worked on millions of computers, especially developers who loved to tinker and modify and customize their setup was no easy feat.
In fact, we spent the majority of our time building this first-time experience, more so than we did the core Crashlytics SDK code!
But it all paid off. Enormously.
Our first-time experience was like nothing developers had seen before. They Tweeted about it. They told their friends. Eventually, by the time Twitter acquired us, we were already on 300 million devices. Today, we’re on almost 3 billion monthly active devices.
Think this was a one-off? Let me give you another example where our focus on first-time experience helped us dominate another category. This time, it wasn’t a niche category like mobile crash reporting.
Next, we were going to go for the crown jewel — mobile analytics itself.
When we were building Answers in 2014, our mobile analytics product built to work with Crashlytics, we were launching a competing product to Google Analytics, the 800-pound gorilla in the analytics space — along with every other product in mobile analytics. And there were many: Flurry, Localytics, Mixpanel, etc.
This space was incredibly competitive with very high stakes. Flurry was reportedly acquired by Yahoo for about $300 million — and they were number two at the time. And Localytics and Mixpanel had each raised almost $100 million, occupying positions three and four on the top list.
When we were doing our initial research, one of the most glaring things we found was the way every other company handled their onboarding process.
You signed up for an account. You added your code. And then, as a first-time user, you were given a dashboard screen — and because it hadn’t collected any data yet, the dashboard was completely empty. A big empty void. There was nothing to do with zeros across the screen and flat-lined bar graphs.
As we went through the onboarding flow of our competitors, we noticed that, as users, our first-time experience didn’t feel very good.
It was very mechanical: Enter your name. Your email. Insert this code. Now look at this empty dashboard.
We thought, “This was what billions of dollars of value looks like for analytics?”
We didn’t want to do that with any of our products. We wanted our first-time users to feel inspired, and for the experience to be thoughtful, and well-crafted.
So, instead of thinking of our onboarding sequence as another box we needed to check-off in order to build an MVP, we spent a considerable amount of time working on that first touch point with a new user.
We didn’t just want them to use our product. We wanted them to love it.
Here’s what we did:
With software products, there tends to be a bias toward more options. It’s the easiest, laziest way to solve a problem. “Should we show the user a dashboard of this first, or that first? Well, let’s have them choose!”
This is the worst way to design and build products.
With the onboarding flow, it is one of the only opportunities where you can force a linear progression in the decision tree of your product.
We took that opportunity and ran with it.
Our onboarding flow was a product experience in its own right. It had just as much thought put into it as the final product experience.
When a user signed up, rather than giving them a million options, we showed them screens in bite-sized chunks. The human mind largely prefers information in digestible chunks (see how even this blog post is chunked out?). Embracing this for onboarding means a much more pleasant experience for the user.
Each easy-to-understand screen only asked for information that we absolutely needed. This meant we didn’t ask for information that we couldn’t use right away.
This is the golden rule:
Don’t ask for information your product can’t use right away. It means higher friction, adds to frustration, and takes away from the overall experience.
Our onboarding flow also required engagement. This meant we didn’t just dump them to an empty dashboard.
As part of the onboarding and first-time experience, we made absolutely sure their code was installed. We deliberately asked them to fire up their app so that it would hit our servers. Of course, this meant extra engineering for us, since instead of simple account creation, we had to add a significant amount of logic to check the status of their own code, in their own app, and then display prompts, etc.
However, this extra effort was worth it.
Because we took the time to do this, it meant we were sure our code was in their app correctly. And our users got to experience the product first hand, right off the bat.
On top of that, instead of throwing them into an empty dashboard, we created a fake dashboard filled with charts, but had it blurred in the background. In the foreground, we presented a small screen that had a spinner on it — and within that modal, we had these animated blocks flying on-screen.
Until it became clear to the user that the blocks assembled… their own app’s logo.
Our users loved that. This was a stark contrast to the form-based onboarding others in the space forced. We saw tweets about our onboarding — how delightful it was, how fun it was, and how personal it felt. This was when we knew we had made something memorable.
Now, you may be wondering why a startup would prioritize spending so much time on the onboarding sequence and not investing that time in the core product instead.
The results speak for themselves.
Crashlytics was ranked #1 in mobile performance, and it had more usage than the platforms sitting at #2 through #6 — combined.
Answers, our mobile analytics product, became the fastest-growing mobile analytics product out there. We beat Flurry and then Google Analytics, and were ranked #1 within 10 months of launch.
At the 1-year marker, Crashlytics was acquired by Twitter.
Then, in 2017, after Answers launched, Crashlytics and Answers were acquired by Google from Twitter.
Obviously, we had to do a lot of other things right to become the leader of the mobile performance and the larger mobile analytics space, but our attention to detail for a new user’s experience is what ignited word of mouth around our products.
We didn’t need marketing. We didn’t need to overspend in those departments other startups allocate so many (too many!) resources to.
When you make something lovable, the product speaks for itself.
So, how do you actually create an unforgettable first-time user experience?
It comes down to the perception of time.
A new user is extremely impatient. They don’t trust you yet. They don’t know what to expect, and they’re trying to decide (as quickly as possible) if you’re going to make their life easier, faster, and more efficient, or slower, more annoying, and boring.
I often draw parallels between product design and video games because, of all industries, games are in the business of time. The more a game can make you feel like an hour has just flown by, the more likely you are to spend another hour, and another hour playing in their world.
And when it comes to first-time user experiences, nobody does it better than gaming companies. From the moment you start a new game, you’re either immersed in it, or you’re gone.
Overwatch, the popular multiplayer game by Blizzard Entertainment, did something interesting with their waiting screen that I find to be a perfect example of creating a lovable product that respects a user’s time.Traditionally, when you’re playing a multiplayer game online, you have to wait for other players to join before the match can start. If it’s 6 vs 6, you need all 12 players — and for most games, players are left sitting in a waiting screen: waiting for all users, finding server, etc.
What Overwatch did, which was clever, was instead of forcing players to wait, they would throw them all into a mini-game. It had no objective, no rules. It was just a leisurely way of spending time interacting with each other in the game world. And instead of opposing players running around and attacking each other, like a normal game, they would do things they wouldn’t normally do — like wave at each other, cooperate, etc. It was a new way to experience the same game, but was the equivalent of a waiting screen.
When a startup company is visualizing their product, they tend to forget the moments a user has to wait.
They draw mockups of the different screens of their product, filling them with an array of charts and numbers and vibrant data sets, only to forget (when their product goes live) that a new user is going to be starting with… nothing. No data. No long term usage. Zilch.
But what about the first time a user sees that dashboard? What about the first time a user looks at their “friend list” or message box?
It’s going to be empty.
Which means it’s your job to examine that specific moment in time and ask, “What can we do to make a user feel included here? How can we make them feel like they’re not waiting for something to happen — but that it’s already happening?”
A lot of startups only approach the product they’re building from an engineering perspective, not a people-centric view.
And people are very aware of time — how they spend it, how long things take, and the relationship between the amount of time they’ve invested and what they’ve gotten in return. The perception of time is very subjective.
Which means, if you’re able to have the user’s mind focus on something else, time will move faster. And boring things like waiting — for a dashboard to populate, for example — will feel much shorter, which makes a user feel engaged and more likely to stick around.
Here are some quick examples of how to make a first-time user feel as though time is moving faster than it actually is.
In general, we would classify these as Progress Indicators.
- Tips for the product: When a new user first enters the product, it can be extremely helpful to give them indicators on where things are and how it works. But this can also be a tactic for continuously keeping them engaged as they continue to use the product over time (as long as it’s done strategically and doesn’t become an annoyance).
- “Did You Know?”: Loading screens are an excellent place to put quick, interesting facts relevant to the product or its use case scenarios.
- Quotes: Slack does this. When you’re waiting for a Slack channel to load, you’re presented with a quirky quote. It’s something to take your mind off the fact that you’re waiting.
- Animations: Loading animations, especially, can help a user feel as though they’re witnessing something creative or unique unfold right in front of them — instead of feeling like they’re waiting, waiting, waiting for something to happen.
- تسلسلات المتابعة: لا يمكنك أن تنسى الوقت الذي يحدث عندما يكون المستخدم بعيدًا عن منتجك. على سبيل المثال، ما سنفعله هو إرسال رسائل بريد إلكتروني مصممة بشكل جميل لمستخدمينا تحتوي على تحديثات مرتجلة تقول أشياء مثل «TL؛ DR - كان تطبيقك خاليًا من الأعطال بنسبة 98.٪ هذا الأسبوع.» هذا التعزيز الإيجابي جعلهم يشعرون بالرضا في الوقت الحالي، وأعطاهم المزيد من الأسباب للعودة والاستمرار في استخدام منتجنا.
الآن، ماذا لو قمت بإنشاء منتج يقوم العديد من المستخدمين من نفس الفريق بتسجيل الدخول إليه؟ كيف يمكنك التأكد من حصولهم جميعًا على نفس تجربة المستخدم التي لا تُنسى لأول مرة؟
هذا شيء واجهناه مع Crashlytics.
لقد تساءل الكثير من الناس كيف تمكنا من الانتشار في مجتمع التحليلات، والحصول على الكثير من الاستخدام، بهذه السرعة.
الحقيقة هي أننا أمضينا الكثير من الوقت في التفكير في كيفية ملاءمة منتجنا لتدفق العمل الطبيعي للمستخدمين العاديين. تحاول العديد من الشركات الناشئة بناء منتجات، على الرغم من أنها قد تكون رائعة من الناحية النظرية، تعمل ضد الإيقاعات اليومية الطبيعية، وسير العمل الطبيعي، والعملاء أنفسهم الذين تتطلع إلى جذبهم.
مثال على ذلك: تقوم الكثير من الشركات بإنشاء منتجات حيث يمكن للمستخدم الاشتراك للحصول على حساب، واستخدام لوحة التحكم، ثم مشاركة معلومات تسجيل الدخول وكلمة المرور مع 10 أعضاء آخرين في الفريق (في حالتنا، المهندسين).
تكمن المشكلة في هذا النهج في أن المنتج يمنح واحدًا فقط من هؤلاء المستخدمين تجربة المستخدم الكاملة لأول مرة.
مما يعني أن تحديثات البريد الإلكتروني أو الإشعارات التي ترسلها كتعزيز إيجابي لا يراها إلا الشخص الذي يرتبط بريده الإلكتروني بالحساب.
هذه ليست تجربة تتمحور حول الأشخاص. هذا مجرد منتج يقوم بما يحتاج إلى القيام به ليعمل.
مع كراشليتكس، سألنا أنفسنا، «كيف يمكننا أن نجعل كل مطور للهواتف المحمولة يتمتع بتجربة مستخدم لا تُنسى لأول مرة - بغض النظر عما إذا كانوا في نفس الفريق مع مطور آخر يستخدم منتجنا؟»
لماذا سألنا أنفسنا هذا؟ لأنه إذا مر شخص ما بهذه التجربة المحببة لأول مرة، فسيخبر شخصًا آخر عنها.
مما يعني أنه إذا مر 10 أشخاص بهذه التجربة المحببة لأول مرة، فسوف يخبرون 10 أشخاص آخرين عنها.
كان هذا تكتيكًا للنمو يركز على الإنسان. وانتشرت كالنار في الهشيم.
كيف قمنا بتصميم هذا هو أننا نظرنا إلى سير العمل الطبيعي للمطور وأدركنا أن جزءًا من روتينه اليومي هو التحقق من الكود الخاص به - إما كل بضع ساعات، مرة واحدة يوميًا، إلخ.
لذلك، أنشأنا تجربة مستخدم حيث بمجرد تنزيل المستخدم #2 للشركة أو مزامنته مع أحدث شفرة مرتبطة بتطبيق تلك الشركة، ستظهر نافذة منبثقة تحتوي على صورة الملف الشخصي للمطور الأول، ورسالة تقول، «مرحبًا، يحتاج جون إلى التحقق من أنك في فريقه. يرجى كتابة عنوان البريد الإلكتروني الخاص بك.»
سيكتبون بريدهم الإلكتروني، والآن أصبحوا مستخدمًا آخر ضمن Crashlytics - مما يعني أنهم يتلقون أيضًا نفس الإشعارات ورسائل البريد الإلكتروني التي تغرس التعزيز الإيجابي.
كان هذا المستوى الصغير من التفاصيل هو الفرق بين كل شركة تطبيقات لديها حساب Crashlytics، وكل مطور داخل شركة لديه حساب Crashlytics الخاص به.
إليك نصيحتي الأخيرة لأي شخص يرغب في بناء تجربة مستخدم لا تُنسى لأول مرة:
يتصور معظم رواد الأعمال منتجهم في أفضل صورة. إنهم يتخيلون ملايين الأشخاص يستخدمونها، ويلتقطون الكثير من البيانات، ويعرضون الكثير من النشاط.
هذا ما أسميه رؤية اليوم 40. إنهم يصنعون نماذج من هذه الرؤية. يبدو رائعًا في مجموعة المستثمرين، ولكن له قيمة قليلة تتجاوز ذلك. يركز عدد قليل من الشركات الناشئة فعليًا على اليوم 0، ثم اليوم الأول، وما إلى ذلك.
ينزل معظم المستخدمين قبل اليوم 40 بوقت طويل. إنهم بحاجة إلى الرؤية باستمرار، و يشعر، براهين القيمة. بخلاف ذلك، سيدخلون تطبيقًا فارغًا، ومنتجًا قديمًا، ولن يجدوا سببًا كبيرًا لمواصلة استخدامه.
هذا هو السبب في أنني أؤكد بشدة على أهمية إنشاء تجربة لأول مرة تقدم قيمة حقيقية، وتُظهر للمستخدم ما يمكن أن يتوقعه من المضي قدمًا، يومًا بعد يوم.
لسوء الحظ، لا تركز معظم الشركات الناشئة على تجربة المستخدم الأولى - وهي تعاني من ذلك. وهذا هو السبب في أن عددًا قليلاً جدًا من المستخدمين يصلون إلى اليوم الأربعين، وعدد قليل جدًا من الشركات تستمر خلال الجولة الأولى من رأس المال.
السؤال الوحيد الذي أطرحه على كل شركة تقريبًا أنا مستثمر أو مستشار أو مرشد لها (وأنا أعمل في أكثر من 50 شركة ناشئة في الوقت الحالي) هو كيف تبدو عملية الإعداد الخاصة بهم.
«كيف تتفاعل مع المستخدمين في اليوم الثاني؟»
تحصل فقط على واحد فرصة لترك انطباع أول جيد. تعد تجربة المرة الأولى مفتاحًا لنجاح منتجك مثل أي من الميزات الأخرى في منتجك، إن لم تكن أكثر أهمية - لأنها الميزة الأولى التي سيتفاعلون معها.
تذكر، يجب عليك كسب الحق في المزيد من وقت المستخدمين.
