In my senior year of college, I enrolled in a course on evidence-based management. With only five other students in my class, the course proved to be quite the immersive experience into the scientific model. We focused theoretical business decision-making on creating hypotheses, observing our environment, gathering data, and refining our initial guesswork.

At the time, I wasn’t sure what to think of the class. Evidence and business seemed like two very distinct disciplines; one very scientific and formulaic, and the other entrenched in creativity and agility.

The idea clicked with me after I left school. Operating from an evidence mindset is not strictly for science geeks—evidence is critical to every aspect of life, from our personal goals to our job performance.

Evidence-based front-end development (quite a mouthful) has played a huge role in my career. Performing my engineering tasks with a logical thought process that encourages best practices and optimized results has allowed me to execute more precisely at greater speeds.

Below I walk through some of my takeaways from adhering to an evidence-based approach to front-end development.

Talk to stakeholders

Understanding who has a stake in your project will identify the correct communication channels. Stakeholders could be a client, upper management, your immediate superior—anyone who has authority over the end product.

People with authority over your project have the ability to muddy the waters. The only times I’ve had this happen to me occurred because of a breakdown in communication. Stakeholders must be a part of the process, from ideation to prototyping to initial release. The feedback they provide gives them the ownership they need to accept your project.

Case in point, I once was tasked with an assignment that involved the design of a login screen. Believing my supervisor was the primary stakeholder, I developed the work under his guidance—and that’s when disaster struck. In a meeting with top management, they hated what I had created, and hearing the reasons why made me realize I had been shutting out essential stakeholders.

This isn’t to say stakeholders should have a final say in how your work evolves. Rather, it’s part of your job to educate your stakeholders with the evidence collected throughout the process (and talking to stakeholders during that process can be a source of evidence). This is why evidence-based front-end development is so powerful—it relies on indisputable evidence rather than subjective reasoning. And if you do run into a disagreement with a stakeholder where you have no evidence, offer to collect that evidence for them; a/b comparisons, user testing, and analytics are all potential streams of evidence from which you can pull.

Review common practices

Front-end engineers have a tendency to reinvent the wheel. Just look at the constantly evolving JavaScript ecosystem. This isn’t a bad thing. Evolution is very much needed and encourages adoption of new techniques and methods that enhance the products we deliver.

However, there comes a point when conventions might be more suitable than trying to find the shiniest new tool. Every task and deliverable almost always has me starting with a Google search. Knowing how others have approached a similar problem and understanding the conventions they employed has helped me to develop solutions that have been proven by the community.

Approaching problems in this manner hasn’t excluded new technologies. Sometimes the right tool is to embrace the newest JavaScript framework. Regardless, I often look toward the community for evidence that a certain convention or tactic is appropriate.

Validate with colleagues

While relying on the outside front-end community can be an excellent resource for your work, looking inward to your own organization is also vital. If you’re part of an engineering team, you likely have individuals around you who have experience and input that can help guide your thought process.

If your team isn’t of the technical background, your coworkers are still a valuable resource from which you can bounce ideas. Non-technical people have an amazing ability to cut down technical puzzles into a relatable experience. As a front-end engineer, I’m often stuck thinking about a problem from the standpoint of the technology. But when I seek advice from marketing, their approach is from a completely different view.

Your team can give you a diversity in thinking that will help you make smarter decisions and uncover essential evidence that otherwise may have remained hidden.

Test that it works

The abundance of consumer devices has made for a hectic front-end world. We have phones, tablets, plain-text emails, responsive sites, competing operating systems, screen readers—you name it. This is the hard part of the job. Front-end engineers are responsible for developing software that works across a broad spectrum of environments under differing user interactions and abilities.

A robust testing suite and methodology will help you produce real, evidence-based data on how your product works in different environments. Knowing that your email will be readable in Gmail web view or that the business blog looks good on the iPhone 7 is the proof you need to guarantee a solid and reliable user experience.

Make the investment in the tools to help get environment testing done appropriately and support the quality assurance department in double-checking your tests. Ensuring product usability before delivery may seem basic, but it’s a complicated and messy process that’s easy to trip over. Producing evidence of testing will give your team confidence in the final product.

Experiment first

The lean startup methodology first gained momentum with Eric Ries’ fantastic book, The Lean Startup, which I highly recommend. In it, he describes an approach to business that shortens the development cycle and focuses on getting products out more rapidly. Customer feedback is gathered and the product improved through constant iteration.

Following a similar approach to your work is an ideal way to gather quick evidence where there is none. Too many times a team will spend enormous quantities of time building, refining, and arguing—only to release a product no one wants. By chunking your work into lower fidelity phases, you’ll spend less time wondering and more time generating evidence that will point you, your team, and your product in the right direction.

Design thinking is another methodology that falls in line with the lean startup thought process. Under this view, it’s your job to think through a problem before delivering any kind of workable solution. Sounds basic, right? Only it’s not. Design thinking relies on research, brainstorming, refinement, testing, and iterating. These are all big steps that require collaboration and concerted effort by every member of your team.

Experimentation is the core to producing evidence. Ask any scientist. Heck, ask any person. We all know that action is necessary for discovery. Developers and designers tend to jump the gun, though, and shift immediately to building. By experimenting and researching, you can build better products with real data to back up your decisions.

Rely on logs for problem solving

When I run into an error with my front-end code, my first inclination is to barrage it with every kind of fix that comes to mind. These fixes are more like hunches and many of them don’t work.

With an evidence-based approach, your hunch should play less of a factor in bug hunting. We have actual data we can look at to figure out why something isn’t working: logs.

Logs are essential to software development. They indicate errors, paths, sources, and other data points that can lead you to find the answer to almost any question. When I was learning Ruby on Rails, every other page refresh of my test application resulted in an error. I had to resist the urge to panic fix the bug and to instead look in the development log to see what was happening. Becoming comfortable with the logs has saved me countless hours of time otherwise wasted on unworkable or inefficient solutions.

Investigating user data analytics is another form of log reliance. If you have a problem with a traffic drop-off, you can put your user data into action and review your website trends to find indications for why people aren’t visiting.

Logs provide hard evidence and should serve as an important tool in your development arsenal. Use this evidence to find concrete answers to the issues that may be plaguing your work.

Document your path

Evidence is dependent on documentation and recordings. We need a reference point to tell us why something is or why something was. Keeping an organized notebook of documents pertaining to your work will remind you of solutions, troubleshooting tactics, resources, and other useful nuggets of information.

I find Evernote to be one of the best tools for recording evidence. With its ability to section off notes into different virtual notebooks, I can keep track of various projects, from front-end applications to house maintenance. And from a team perspective, Github has become a great home for documentation and troubleshooting guides.

Regardless of your tool of choice, get into the habit of recording your methods of finding evidence as well as the evidence you have found. You may come to find these notes have turned into valuable evidence themselves for future projects.

Conduct postmortems

A postmortem sounds grim, like an autopsy on a failed project where we don’t know what the next incision will reveal. But postmortems aren’t quite so gloomy. Whether the project was a success or failure, understanding the reasons behind a project’s fate can help you to develop an evidence-based track for other projects.

There’s no cut-and-dry way to conduct a postmortem, and quite frankly, few teams actually implement them. However, I think reflection is a powerful tool for teams to improve their internal capabilities and to better understand the external forces that may bear down on them.

The essential guidance behind a postmortem is that it’s a written document that involves the entire team and explores the project’s complete lifecycle. These documents must result in action, and they should act as a pillar of guidance in the framework from which the team operates.

Living with evidence

Evidence-based front-end development may sound cold, calculating, and over-hyphenated, but it’s a mindset we should all strive to adopt and foster within our teams. Evidence is the key to determining if our hypotheses are correct, to seeking answers to our problems, to getting to the “why” behind the “why” behind even more “whys.”

And really, this is the most important takeaway: operating from evidence is a way of living. There aren’t any tools that will make you an evidence-based developer. You have to practice it and learn how to use the evidence you find.

On a final note, the evidence mindset doesn’t just stop of development. When I say it’s a way of living, I mean it. Evidence is all around us—in our hobbies, relationships, professional work, and journeys. Always use evidence to help with your decision-making, because sometimes your gut just doesn’t know what it’s thinking.