It’s clear the importance and value of having a tech team with strong Software Engineering skills. Things like defining the right architecture or building systems that perform optimally are really important when you are building products that need to be scalable and are going to be used by millions of users.
But when you are building more innovative products, like immersive experiences (AR/VR), gamified products or incorporating Play Thinking into an experience, your tech team will need to practice what we call User-Centric Engineering.
User… what ?
User-Centric Engineering is all about elevating engineering perspectives and practices to meet the unique challenges of innovative experiences that don't necessarily have precedents or best practices to rely on.
User-Centric Engineers work towards the best interests of the end user, rather than focusing primarily on completing tickets or working on purely technical tasks. They make sure to understand the intent behind the design and experience so they can ask the right questions and ensure that the features implemented bring the most value to the user. This helps to reduce blind spots and ultimately improve the user experience. User-Centric Engineers also know when to break some rules, when to follow them and even when it’s time to create new ones.
Engineers are a fundamental part of the design process, you can only reach the best user experience when you have user-centric engineers integrated into the design process. For more innovative projects, the solid foundation that rigorous software engineering can provide is unquestionably an important piece. However, it’s equally or even more important to have a team that knows how and when to bend or break the rules of traditional product management, product design and software engineering. Why? Because playfulness is not a feature, it’s an experience. You can’t scope fun, you need to discover it.
To do this successfully your team needs to know when to be rigorous and when to be scrappy. It’s a balancing act that requires a good deal of experience and trust within the team. People will need to unlearn old patterns and old ways of doing things in order to make room for learning new ways, or in some cases, create new ways. This might be difficult for some, and that’s why flexibility and trust within the team is really important.
Unlearning to relearn
One of the most important requirements for an immersive experience or gaming-inspired product is that it needs to be engaging and fun. After all, in such a crowded market for digital experiences, enjoyment is key to engagement.
In traditional product development you and the team will break down a pre-defined feature into tasks and then estimate them. In this case, the traditional definition of success will be to accomplish all the tasks in the estimated time or less. But, what if user testers or team members say the experience is repetitive, boring or that it lacks user agency? Here is when you might want to break some old-learned rules. What if you prioritize a short exploration phase over a clearly defined feature? An exploration that is scrappy but proves a point? These explorations don’t need to follow software engineering best practices, require you to unit test your code, or obsess over architecture. A good exploration will have more gray boxes than polished assets. The goal is to quickly learn about what’s engaging and what’s not, iterate based on those learnings, and ultimately discover what your users enjoy and engage with the most.
A few examples of quick prototypes for a new type of sensor hardware, we created many more of these types of prototypes in order to discover what’s more engaging and fun.
Once you have discovered the fun and what's most engaging, you can go back to scoping and planning for a solid integration of what you just have learned. Back to following the rules.
The more you and your team flex this muscle of unlearning and relearning, and practicing when to be scrappy and when to be rigorous, the better it will be for your projects. At the beginning, there might be some resistance: after all, this is not what you are “supposed” to do, right? you are “supposed” to hit the deadline for the project with all the features the product was “supposed” to have. But in reality, if your product is not engaging, users might just drop it before even exploring its features. This is especially important for immersive and gamified projects, which explicitly compete on their enjoyability and immersiveness.
You might feel tempted to think that you or your team has a good idea of what’s actually fun and engaging, and just scope that and stick to the traditional plan without having to “spend time exploring”. Well, if that’s the case I can tell you that you are not the first person to think their ideas are the ones that are going to work. When you take an idea and test it, it teaches you important lessons, but if not, that idea is just a (probably biased) assumption.
As an example, during the prototyping phase of an immersive project we worked on, we all were super excited about the potential of one of the prototypes, we thought that prototype was going to be “the one”. But when we user-tested it, users didn’t like it much at all. Users said they didn’t get it and that it was confusing and boring, and ultimately, it ranked as one of the least liked.
In terms of creating engaging experiences, you really want to base your project decisions on learnings from user-testing. Listen to your users, not to your assumptions. Exploration is key.
Embracing failure
Often we are tasked to build “first of its kind” experiences, from a brand new experience for an existing or new platform, to a showcase experience for new upcoming hardware. When you work on these types of challenges there is no precedent, no right or wrong, no previous experience, everything could be possible, or not. The only way to uncover what works is to try to break things by pushing the limits and most importantly, to fail as often and early as possible. You need to navigate ambiguity by embracing failure.
The more you try things that break and fail early on, the more you learn about the platform or hardware. And the more you learn about the platform or hardware, the better you can inform decisions and the team can find creative ways to build an engaging experience no matter the limitations of the platform or hardware. It's quite likely you might need to pivot a few times as you learn more, but that’s just a sign you are doing a good job at pushing the limits and using everything the platform or hardware has to offer in order to build a great experience.
Just because this approach works really well for these “first of its kind” projects, it doesn’t mean it can’t be applied to others. This approach can help you in any challenge that requires you and the team to navigate ambiguity. It will help you get to that point of having a great experience, when it’s hard to know how to get there by using traditional methods of product development.
Unleash the collective genius
We wouldn't be able to build such great experiences if it wasn't for our highly collaborative teams. (User-Centric) Engineers, Designers, Artists, Strategists and Project Managers are all equal when it comes to bringing ideas to the table. Even if an idea doesn’t “work out”, you will learn from its failure. In the end, all that insight will help you build a better experience. The more diverse the set of ideas and collaboration the better. It will help you approach the challenge from different perspectives and reduce blindspots. You really don’t want one person alone deciding what the experience should be, it will probably be biased and missing a lot of untapped potential.
Engineers are an essential part of the design process and the more they think about the user the better is going to be for the products and experiences your team creates. To foster a user-centric culture with your engineers, start to involve them early on in projects, even if there is no technical work to be done. Include them in kick-off workshops, stakeholder interviews, brainstorming and ideation sessions. To create a good product or experience every discipline should have some sense of ownership. Genius is in the collective, not in individuals.
