This post was originally published on the Slalom Technology blog.
___
I’ve been a developer for over 20 years and I just created my first Easter Egg! I am a big fan of Stranger Things on Netflix, so I decided, at the advice of my colleague Erik, to create a Stranger Things Easter Egg. You can view it here. It was fun, easy, and got our development team and stakeholders a little excited. I started to think about why I haven’t done this sooner, and the bigger question: should we have Easter Eggs in our workplace applications?
An Easter Egg in software is something users find by accident, or through word of mouth. Much like our children hunting for eggs on Easter Day, our software’s Easter Eggs shouldn’t be in plain sight, or documented, as that defeats the purpose.
There are Easter Eggs in so many applications you and I use today. They are commonly found in consumer-facing websites, applications, and games. The latest one I learned about was Google Chrome’s dinosaur game. When your browser can’t connect and you see the dinosaur (as seen on the left), press the spacebar. You can also play this by going to chrome://dino (Chrome browser only)
You’re welcome.
Benefits of Easter Eggs
Easter Eggs are great, like a child finding an egg, these are just as exciting! They are little nuggets of gold: they’re usually fun, can be useful, and promote people looking around. This type of interaction promotes deeper engagement with your application, which is what we all want! When one is found, it can quickly spread over Slack to other users, discussed in meetings, and shown in the hallway. We love experiencing it ourselves and showing it off. It creates an “in” crowd that people want to be a part of.
For the ones creating the egg, it brings some excitement as well. It’s fun for end-users to find them and fun for developers to build them! It can help bolster a culture encouraging creativity, self-ownership, and pride for the developers.
Eggs can be a growth opportunity for your developers as well. As they build it, they will be in the code, learning it more, trying new ideas, etc. Learning by doing is the best way to learn! This is all good for your team and your application. You could spin egg creation into a hack-a-thon, which could be done after hours, again promoting your team and your application.
They don’t all have to be cute and fun, they can be useful too. As we continually improve our products and applications for our employees, we can sneak in new features as Easter Eggs. Instead of pushing out a feature and sharing it in release notes, consider just letting it go into the next release, and wait. Don’t make it too obvious, hide it a little. Track usage analytics and always be willing to accept feedback. Later on, once you know it’s good, share it in release notes and other communications.
For example, one idea I’m leaning towards is to add keyboard shortcuts to the application. This is a simple use case and can be very useful, something like this can be rolled out quietly. Some will people hit the keyboard by accident and find it, then there can be a little animation and a dialog after they find it so they know what they found. Later on, we can announce it as we refine it and build out more capabilities around it.
One Bad Egg Spoils the Bunch
As much fun as this can be, we have to take care. There are a few potential risks, but they can be easily handled.
Easter Eggs do take time to build. My client pointed out “obviously we would try to minimize the optics of impact on overall product development and throughput”. Totally agree. In my example above, I built that over my lunch hour, no big deal. If the Easter Egg is an early feature, then there’s no loss of work. For fun eggs, as the stakeholders and others see it, make sure to explain what went into it: minimal time, lunch hour, after hours, existing code, etc. I do believe using “real” time: project time, sprint time; to build a fun egg can far outweigh the costs.
Easter Eggs are inside your production code. This is the part that can be terrifying. Since this is a code change, it should be tested to ensure we’re not introducing bugs, and itself doesn’t have bugs. It would be a bad Easter Egg if it breaks the app. In my example, I put all of the code in a completely separate code file, and just referenced it from our primary code, adding only 3 lines of code. Super easy to test and remove if needed.
Easter Eggs, the fun ones, should be very well hidden. If the egg is too obvious, it may become an annoyance, or even block productivity. In my example, the user has to type in the phrase Stranger Things, it’s case sensitive and it has to match exactly. Typing in stranger things won’t do it. After the page rotates the user can still interact and use the page, although in The Upside Down. Simply pressing F5 to refresh clears it.
Try it
Give it a try. Have the conversation with your team, I bet there will be interest. Start small, like my Stranger Things example, something hidden and fun. Consider it as a plan for the next feature you want to roll out. Everyone loves Easter Eggs, let’s bring that into the workplace and have some fun.
