Follow the Packet
What my unrelated college degree taught me about design research.
“JP I’m trying to ping the PIX from the 2600 over here but I’m not…”
“Follow ze paquette” (strong French accent)
“OK cool, so that seems to be working now but I’m plugged into this switch and…”
“Follow ze paquette”
“Awesome, well now Router 1 can’t seem to find Router 3 so…”
*disappointed glare*
I didn't always know that I wanted to be a product designer, UX designer, interaction designer, UX architect, or whatever ill-defined title they are using for people who do something vaguely similar to what I do these days. When senior year of high school rolled around and it came time to choose my destiny, I made the logical choice for any computer nerd with limited information on what the real world is like — I chose an electrical engineering program at a small engineering school far, far away.
I lasted a solid 6 months before I realized that this was not what I wanted to be doing with my time. I dropped out. I moved back home and re-started my business repairing computers and setting up networks for homes and businesses in my small town. I liked it, I was making enough money to fund my PC gaming habit, and it seemed to come natural to me. Feeling the pressure to go back to school, I enrolled in a Computer Networking degree program at a local community college with intentions of transferring to a 4-year school as soon as I was sure that this was what I wanted to be doing.
Please Do Not Throw Sausage Pizza Away
A mantra I still live by.
We started off with the basics. While I had been working with networks and servers for years and believed that I knew my shit (spoiler: I didn't), the networking program was designed with the novice in mind. On day one, we learned the OSI model with the help of a friendly mnemonic device that I will never forget because it marries my love of computers and pizza.
Please Do Not Throw Sausage Pizza Away
The OSI model was designed as a framework for describing how two or more networked devices could communicate.
- At the top – Layers 7 6 5 and 4 – your application comes up with some stuff it wants to send out to the rest of the network. After defining what it wants to do and where it’s going, it packages everything up and sends it down the line.
- The network layer takes a look at it, says “Yeah, I think I know a guy who could get this to your guy” and repackages it to send down to the Data Link layer who *knows the guy*.
- Well, unfortunately his guy can understand english but his friends can’t so he has to repackage it once more, writing a bunch of bleeps and bloops on the package before sending it out on the wire.
- Eventually the package arrives at its destination and the whole process happens again in reverse.
Think of it like Russian nesting dolls, or the way Amazon merchants sometimes decide to package the single tube of toothpaste I ordered.
Following Packets
Fast forward a year or two and I have the OSI model, TCP/IP model, and various other models thoroughly etched into the back of my brain. I move to Chicago to finish up my degree at DePaul University’s College of Computing and Digital Media. This time around, my choice of school was well informed. Ultimately, it came down to 3 main requirements.
- Located in a major metropolitan downtown – for the internship possibilities
- Lots of lab-focused coursework – I didn't want to spend all day designing networks exclusively in simulators
- A crazy-awesome french guy leading the program.
Actually the third one was added later. His name was Jean-Philippe Labruyere or JP for short.
Thankfully, we did get to spend a lot of time in the lab and I’m always grateful that I got the chance to do hands-on work with hundreds of thousands of dollars worth of network equipment before we were playing for keeps. However, I’m even more grateful for learning the one phrase I could always go back to anytime I was stuck on a problem.
“Follow the packet”
Follow the packet was JP’s way of saying “Ok, you know the steps that one device takes to communicate with another, you know the OSI model, you know how this thing works, now go through all the steps in order until you find out which step was messing things up.” Saying “follow the packet” was easier.
One by one, we’d go through the steps, starting at the bottom, just like Drake.
Can’t ping a device?
- Is it plugged in? Check
- Does this cable actually work though? Check
- Does the switch light up properly? Check
- Is the switch port active? Check
- …
- …
- …
- OK what do the inbound firewall rules look like? oh. whoops.
“Follow the packet” became an inside joke for anyone in the program but at the same time we knew how effective it was. If you understood the framework and you stepped through everything in order, you would find the problem 100% of the time.
Layer 8
The user layer.
By the time I was ready to graduate I had almost made my mind up. Networks were cool but there was a reason I liked my computer repair business in high school and college. As it turned out, most of my house calls were not about swapping out fried sticks of RAM or power supplies, but about teaching people how to use the software already on their computer. Whether it was cleaning up some malware that made its way onto the system as a result of some UX dark patterns during an install process, or just teaching someone how to back up their photos, those were the problems everyday people were having. I wanted to make them go away.
What if I just made better software the first time around?
Thankfully I was working at a startup during my senior year so my transition from DevOps/Network Engineer to Interaction Designer was actually a possibility. I started to take on some projects that blended my technical background with what would probably get branded as service design. Working with the customer care team, I designed and implemented the entire phone-based portion of our business – a substantial chunk of our revenue at the time – as we scaled from 2 to 30+ agents.
Of course, this didn't come without problems along the way. During implementation I heard things like:
“Scott doesn't seem to be getting any calls on his phone”
“Alex just had someone say they didn't hear a greeting when they called and it went straight to him”
So I would look into them. There were times I went straight into the phone tree and started listening to the greetings to make sure I had loaded up the correct one. Then I would try calling the number myself, even going as far as having everyone else go “offline” to ensure that Scott would get the call. This was wasted time. I didn't stick to the mantra.
Follow the packet
Scott’s phone was unplugged. Someone bumped it when they walked by his desk. Alex’s customer didn't hear the greeting because they called directly to the phone and not to the 1–800 number.
Eventually I went on to tackle larger design challenges but the strategy didn't change. In 2013 when Edmodo decided to start building a tool for teachers to create common-core aligned quizzes for their students, we started building the product before we fully understood the problem. Realizing what was at stake, we took a step back and realized that if we were going to build a very structured assessment tool that we expected teachers to use in their classroom, potentially every day, we better be damn sure we know what “every day” looks like. So we followed the packet.
We flew to schools all across America asking teachers how they find out what they are supposed to be teaching in their classroom.
So what are you testing your kids on today?
“Oh, well, they’re learning how to add fractions”
How did you decide today was the day for fractions?
“Well, it’s on the CCSS.MATH.CONTENT.5.NF.A.1 standard”
How did you know what was on that standard?
“Well we have this site…”
*shows site*
How did you decide when to put it into your lesson?
“Well, at the beginning of the year we meet with…”
… more questions …
“… more answers …”
Thanks, that was all very helpful!
We asked questions until we fully understood what it was like to be a 7th grade teacher who wanted to know if her students were prepared for the upcoming state-wide exams. We had the framework nailed down. It was like our very own OSI model for assessment. Feature development was no longer a guessing game and when it came time to decide how to label a button or how to group information together, we could follow the packet, and we knew exactly where our own product stood as standards travel from the education boards, to the states, to the districts, to the schools (but sometimes to district curriculum specialists, so many variables!), to the teachers, and ultimately to the students.
Looking Back
If I could do it all over again, would I have gone to design school? That’s hard to say. It would certainly make getting hired at large companies a bit easier. But at the same time, I like being the designer who got to nerd out when the guys from Docker came to the Edmodo office to talk infrastructure and the future of container-based deployments. Had I gone to design school, I’m sure I would have learned a lot of the same principles explained in a different manner. Maybe “Express-Test-Cycle” would be my mantra. Who knows. For now, it’s all packets to me.
Special thanks to Cisco Certified Internetwork Engineer #1644 Jean-Philippe for teaching me everything I need to know about app design and @jbouvier and @jonkawa for taking a chance on me.
