Good design is design that looks so simple people assume it took mere hours to come up with and execute. It’s refreshing and allows the user to feel confident as they navigate through. It assists the user when necessary, and allows the UI to excite users and keep them engaged. But, good design looks so simple because of the months of research, wire-framing, iterations and failures. It’s so simple because the user feedback during testing has helped focus the team on what truly matters.
At PlayerZero, our one and only audience for the initial product is a Developer. Developers are a unique crew compared to everyday users, consumers and companies, their idea of good design was unique as well. But, I had the benefit of being at a startup tech company where my coworkers were also our consumers. After endless questions, research, tutorials and learning about the industry with teammates and potential users, I narrowed down our foundational design principles to 6 overarching tenets. If we could continuously keep these ideals top of mind, we could successfully* design a product for developers.
1. Understanding a technical mind
“It’s a bit like when you’re traveling in a foreign country. The locals don’t generally expect you to be fluent in their language, but they do like you to at least have a go.” (John Murray)
Our biggest challenge as a team was to take a complex debugging problem, and implement an effective, efficient solution. Developers value this over a *pretty* or robust tool. And the reason is, that pretty doesn’t help them work faster, smarter, and better. There is a constant timeline and a team always relying on you to get work done (and done well).
The design and experience for PlayerZero had to show the developers that we knew the problems they had. And not only could we solve them, but do it in a way that shows we understood their workflow: programming, debugging and deployment and fit into it seamlessly. Beta testers wanted to know “How does this work and how does it help me specifically?”
Goal: Focus on making the debugging process happen less often and simple.
2. Don’t fight the system (play well with others)
Once I had a strong understanding of the development world, I could clearly see that developers have a refined process. And, they stick to it. There is no time for deviations. Things keep getting more complex, and adding new tools into a process typically doesn’t feel easy. So, PlayerZero had to fit.
Developers live and breathe in an IDE and the terminal. Tools must “fit into a developer ecosystem.” We can not force PlayerZero to solely live in a browser. We can not create a swivel chair experience, forcing them to move back and forth between these tools often. If it doesn’t play well with their current tools, it won’t survive. Also, while PlayerZero is an independent tool, it needs to also offer ways to collaborate with other programs that are in a normal developer's stack - continuously allowing the process to evolve and become easier to do.
Goal: Focus on creating a tool where the primary setup and base information was in a browser, but the core functionality and day to day actions live where the developer was – in the terminal.
Source: Samuel Giddens - Realm Academy
3. Developers are authors
One of the biggest discoveries for me was understanding what developers ACTUALLY did. Sure, they create - they bring experiences and designs to life. Sure, they problem-solve – they figure out complex problems as they work and implement solutions. But, at the core, developers are writers. They use words to bring designers flat ideas to life. They use words to tell a digital, interactive story – and it’s quite beautiful to see come to life.
These words are more than a story, a book or a poem, they’re instructions. AND they’re in multiple languages that work in harmony together – which is absolutely wild to the average person. Developers give computers instructions via code with a set of visual and backend rules and expectations. We obviously can’t cover all aspects to ensure that developers are writing these instructions correctly, but we can help them be better storytellers.
Goal: Focus on being a tool for writers - just like a basic notepad.
4. Lone wolves + pack mentality
The design world is often about constant collaboration, pair designing, and feedback. My experience with the development world shows that developers tend to work alone, but with team based goals in a shared environment. A tool that understands branching, projects and collaboration is key for successful development. Most importantly, in my research I saw that other tools in the tech world that were successful all did one thing well: allow the developers to get in, see full value from their tool, on their own and at no cost.
Once they establish a trust in the product and see value, they tell their teams, friends and share the news. Development tools are not successful because of great advertising or PR. They’re great because of their inherent value upfront to the individual. Then they spread like wildfire.
Goal: Focus on providing value to the individual developer, but allow for limitless team growth and sharing in a community.
5. Lend a hand only when needed
“Developers are highly competent, driven by technical achievement, and skeptical of everything.”
While testing some early hypotheses around the setup, we immediately saw that developers had mixed feelings about hand holding during onboarding. Some didn’t want coaching or walkthroughs. Some wanted a lot of help. One thing was clear - they all want to get their hands dirty and figure out the magic behind the tool on their own. We need to offer a way for users to play in a sandbox environment, set up demos, click around the site, and receive help only in moments when they ask for it. A beta tester summed up our discovery: “Follow the workflow first and then fill in the blanks for confidence…”
Goal: Focus on creating a simple UI that allows for exploration and offer descriptions, tooltips, and walkthroughs throughout if the user needs assistance.
The final and our most important discovery is the need for control over a product. While most consumers want to be told how to do something easily and desire less complexity, developers are the complete opposite. Developers can also handle more complexity than the average consumer when it comes to tech – no surprise there since they speak multiple languages!
While beta testing, one developer said, “I’ve been trained by all the testing tools I use that it’s a time commitment.”
If we ask for them to invest, it must be flexible to hit unique goals, methods, and team structure.
Creating a product that allows for each user to have control is essential: control over the setup, control over the tests that are run and which specific events are discovered, and control over which environments are trained and tested within. However, there is a necessary balance: we also should ensure PlayerZero stays a simple and easy product for new users to see value in.
Goal: Focus on allowing full customization without cluttering a simple experience.
Product Design Techniques
When building any product, it's crucial to have a consistent North star helping guide the design process . At PlayerZero, we've put in the work early to cement our six core tenets for building an impactful product for our users; we will continue to refer to it when facing big questions while also using it as inspiration during our journey. I imagine there will be endless discoveries as we continue to test and understand the development world better and better, but this foundation gives myself and the team confidence that we are moving in the right direction for the first version of PlayerZero.
Today, development and testing is a “been a bit of a clown car.” The combination of a design eye to developer specific problems is a delicate dance that, when executed, will change the way we look at shipping code. A rare combination of design and tech. A new solution to give developers confidence in their code. PlayerZero.
Source: Anonymous Beta Tester