From their website, Stir Trek is:
Stir Trek is a one-day conference focused on teaching software developers, and others in the industry, the latest and greatest in technologies, techniques, and tools. The full day of content is always concluded with a screening of a blockbuster film on its (originally scheduled) opening day. Pretty sweet, huh?
The 2018 Stir Trek conference was held at the AMC theaters in the Easton mall in Columbus, Ohio. It was a welcome change from the thought experiment last year, where the conference was held at the Schottenstein Arena… Sound bleed and crowd management made that year less productive for me.
I missed the UX in API talk, which received both raving and super disappointed views from my co-workers; if anyone has notes they’d like to share, please send them my way! I was disappointed Kevin Holtz was unable to make it… I wanted to hear his talk about injecting developers into the business. Seemed like a super intriguing concept.
Per usual, I stuck mostly to the “Design” and “Soft Skills” at Stir Trek, though I did branch out into QA and other fields. See below for my notes with a quick summary of each.
Side-note: This will likely be my last conference sketching on my trusty Samsung Galaxy Note 8.0. The pen is getting kind of jumpy, and the apps kept randomly switching colors on me (going from black to white so I thought perhaps the pen wasn’t writing at all). I’m looking forward to upgrading to the Note 10.1, both for conference and work purposes, and retiring the 8.0 to sit at home as a media device only.
Brandon Bruno’s talk about improving your inbox by improving your outbox was my favorite talk of the day. Bruno has a background in computer science with a minor in English (like me!) and it was obvious by the way he crafted his presentation. His narrative structure took us through the rise and fall of email and culminated with quick, easy to remember actions you can take to write a better email so you receive a better email.
He claims the goal isn’t Inbox Zero, but rather, craft your message so you receive a message you can do something about.
Kim McGill is an entertaining speaker, very compelling to listen to. I feel like I’d probably love being on her scrum team, but definitely dislike being on the wrong end of a pointy stick. She gave a nice overview about behavioral science with the appropriate disclaimers that this isn’t her field of study.
I loved her point that everyone should be a leader by behavior, rather than role. Don’t rely on the hierarchy to provide leadership, we should all be behavioral leaders of positive change in our own right.
Chris DeMars gave a nice reminder for everyone that accessibility is no longer a requirement, it’s a must do along with security and performance. I mean, unless you want to run the risk of a lawsuit for your company. He had super interesting statistic about how New York and Florida have the largest accessibility lawsuit counts (due to population size and larger older generation population, respectively). But hey, Ohio still had 8 lawsuits in 2016 (?), so it’s not like we’re completely off the radar.
This talk floundered a little, I think, because of the theatre set up. It was pretty clear that Agnel Thomas is used to a far more interactive talk, with attendees collaborating in the presentation. That said, it was a pretty great UX talk disguised as a requirements gathering talk! This was all about reading the words, tonality, and body language of your audience to determine whether you were getting close to their true need rather than their communicated want.
I could have used more action items to take away from this discussion. Something as simple as The Five Why’s would have really helped this crowd, I think.
Anna Heiermann’s talk about risk-based testing is probably the first QA-led talk I’ve attended in a long time (or ever?). I liked her idea of creating a Risk Assessment Matrix early in the development life-cycle so all stakeholders are aware of the key functions, priorities from the client and tech perspectives, any testing notes, and the overall criticality prior to actually testing the feature. I also really liked the idea of prioritizing test cases… Which test cases must pass because they’re the most critical for the end user or system (or both)? I know as a UX designer, I often have to prioritize feature designs, it makes sense to apply a similar thought process to test cases.