We are all scientists!
Geek. Nerd. Techie. Hipster. Artiste. Eccentric. Often left-brained, scientific-thinkers are painted as the antithesis of right-brained, highly creative peers. But if we think about how we go about our daily tasks of creating and maintaining our institutions’ websites, we may realize we’re more alike than we thought — we may all be a little more science-minded than we expected.
The HighEdWeb 2012 keynote speaker Adam Savage reminded us that art and science are intimately intertwined. One of the first steps of the scientific method –forming a hypothesis– is “hugely creative.” We have to step outside our comfort zones of what we *know* to be true and make a guess at what we think to be true.
The scientific method sounds intense but many of us use its tenants every day at work.
Whether a programmer, a content editor, a designer or someone in between, using the scientific method may be nothing new to us in our profession.
What is the Scientific Method?
1. Observe and describe
When we encounter a problem, generally we take note of it and depending on our role, we then….
2. Form a hypothesis
This is a fancy way of saying, “Here’s what I think the issue might be.”
When we get the dreaded call, “The site won’t work,” we have a slew of questions we ask to try to narrow down the problem. Why? Because we understand that an internal server error is quite different from a page not found error. We’re relying on site users to observe and describe the problem, so we can then replicate the error. Once we’re able to do so, we’re on to forming our best guess as to what the problem is — our hypothesis.
And this leads us to:
3. Testing the hypothesis
This is where we try things to correct the problem or even replicate the problem. Anyone who’s had to track down a problem with code, html or css knows that you only change one thing at a time while testing. This ensures that the data can be as accurate as possible.
Data? you ask. I’m just trying to figure out why the site is down. Yep. Data. As you truck along, trying one thing at a time to figure out how to fix the site, keep in mind that really you’re gathering data, even if the data is, “..this worked…that did not…this made it worse…this helped a little…” This is also important for the often dreaded incident reports we must complete when there’s an error on our site or server. It’s also the last step:
4. Analyze and report
After testing and analyzing your data, you then come to some sort of conclusion, “Oh, the page was deleted, therefore the 404 error” or “Our site was compromised by some folks with IPs in the Netherlands.”
You may be thinking, “but a programmer is really like a scientist. I’m a designer/writer/rainbow painter.”
Think about these steps in the context of a designer or writer. After viewing site analytics, gathering feedback from students and conducting usability tests, you may make some assumptions (hypotheses) about a better way to present the information. The best way to determine if your guesses really *are* good guesses is to test, test, test! As you test, analyze the data you gathered. A good scientist will adjust her hypothesis after testing and analysis, just as a good web developer/designer/UX person will adjust, test, adjust, test to ensure that a site visitor’s experience is always improving.
See, we’re all scientists and we may not have known it!