The importance of having a tech team with strong software engineering skills is obvious.
But when you are building more innovative products, like immersive experiences (AR/VR), gamified products or products that incorporate Play Thinking – our design philosophy that centres the emotional response in the user’s experience – your tech team will need to practise what we at ustwo call “user-centric engineering”: working towards the best interests and needs of the end user, rather than focusing primarily on completing tickets or working on purely technical tasks.
Breaking the rules
Engineers are an essential part of the design process, and when they understand the intent behind the design and experience from the get-go, they can ask the right questions and ensure that the features implemented bring the most value to the user.
The solid foundation that rigorous software engineering can provide, especially for more innovative products, is an unquestionably integral part of creating a product or experience. However, it’s equally important – sometimes 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 both 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, creating new ways. This might be difficult for some, and that’s why having flexibility and trust within the team is important.
Unlearning to relearn
Immersive experiences or gaming-inspired products compete on their enjoyability and need to be engaging and fun to stand out in a crowded market.
In traditional product development, the team breaks down a pre-defined feature into tasks and then estimates them, and the definition of “success” is accomplishing 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 established rules. What if, instead of focussing on this traditional idea of “success”, you prioritise a short and scrappy exploration phase outside of typical software engineering best practices like unit testing code or obsessing over architecture? A valuable exploration will have more grey 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.
You need to base your project decisions on learnings from user testing. Listen to your users, not to your assumptions. You might 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. But exploration is key. Testing an idea can uncover what might be biassed assumptions.
For example, during the prototyping phase of an immersive project we worked on, we were all very excited about the potential of one of the prototypes and thought that it was going to be “the one”. But when we user-tested it, this prototype was among the least liked by subjects, who said they didn’t get it and found it confusing and boring. If we hadn’t incorporated a user-centric approach in this part of the design and development process, we would have continued developing a product that didn’t resonate with users.
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 what’s most fun and engaging, you can go back to following the “rules”, scoping and planning for a solid integration of what you just have learned.
The more you and your team flex this muscle of unlearning and relearning, and practising when to be scrappy and when to be rigorous, the better it will be for your projects. There might be some resistance at the beginning, since this process is not what you are traditionally “supposed” to do: hit the deadline for the project with all the features the product was “supposed” to have. But a user-centric approach will ultimately yield a more successful product.
User-centric engineering elevates engineering perspectives and practices to meet the unique challenges of innovative experiences that don’t necessarily have precedents or best practices to rely on. In fact, this user-centric approach can be useful for any challenge that requires your team to navigate ambiguity, not only “first-of-its-kind” experience.
In such cases, the only way to uncover what works is pushing the limits, failing often but early and 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.
You will likely need to pivot a few times as you learn more – which is 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.
An all-disciplines ideation workshop realized at ustwo offices. Genius is in the collective!
Unleash the collective genius
We need highly collaborative teams in which every discipline has some sense of ownership and input in order to create a truly successful product or experience.
To foster a user-centric culture and approach 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. If we want to make products and experiences that are truly enjoyable and user-friendly, let’s ensure that everyone involved in the end-to-end design process has a voice from the beginning – and a user-centric mindset.