The short takes
- I took some of my own advice (and it worked out well)
- I was reminded (yet again) how much enthusiastic and dedicated people can accomplish in a short time (if only we could bottle that…)
- Keep your eye on the prize (and keep reminding yourself what the prize is)
The full-meal deal
This past weekend (Nov. 6-7, 2015), I attended the Seattle Social Justice Hackathon sponsored by the Seattle University Law School. This appealed to my latent activist persona (who doesn’t get out as much as he should), and I felt that a collection of designers, developers, lawyers, and social activists would, if nothing else, make for an interesting evening.
I wasn’t disappointed.
Friday evening, I mingled with the early arrivals and sensed an ambient mood of curiosity. While some had ideas, most were like me—there to see what would happen and how they might contribute. The vast majority, we would learn later were, like me, attending the first hackathon of their lives.
We listened to a few pitches. While all were worthy, not all were problems that a software hack could address, some pitches seemed like a solution might already exist, and some were projects that needed more development. An interesting set of challenges for the group.
Forming
The project that resonated with me was one to help self-represented litigants (SRLs), a.k.a. pro se litigants. There’s a saying that, “A lawyer who represents him/herself has a fool for a client.“ If that’s true for lawyers, what about someone with no legal training?
Well, that project resonated with me because I’ve been there, and done that. While I might have been a fool (although, the outcome was actually quite satisfactory in my case), it was still no easy task and I’m for anything that can help make that role easier for the next person in that situation. I would learn during the event that my experience was not uncommon and that an estimated 36-million people become pro se litigants each year in the U.S. I would also learn how poorly the statistics are kept in that this is probably underreported.
Storming
The SRL project also attracted a couple of mobile-software developers, a research engineer from Microsoft, and a professional UX designer. So, what did I have to offer? My title was officially UX researcher, which was probably close enough, but everyone on our team did what they could when they could so the roles were a little fluid. Initially, I worked with our team’s UX designer to understand the problem space and the possible solutions. Later on, I also did some user research to test and validate our design assumptions.
As the project came together, I focused on my project deliverable, the all-important PowerPoint. Not very technical, but VERY important.
Norming
The important thing to remember throughout the event is that the deliverable is not a solution, but a pitch. The pitch happens to include a solution; but, the pitch cannot include ONLY a solution.
I’ll say that again: The pitch cannot show ONLY a solution.
The pitch must include:
- the problem
- its scope
- the solution
- its impact
Taking out one of those elements has the same effect as taking off one of the legs of a table—the pitch falls over. The hackathon provided a list of more specific criteria, but the pitch coaches helped keep us focused on these points. My contribution was to build and maintain the narrative of the pitch and the solution.
Performing
I kept my distance from the development so, the developers might have a different story about this, but it seemed to me that throughout the event, the technical solution remained relatively consistent or, if it wasn’t, it was at least in capable hands. The narrative and context of the app we would demo, however, evolved throughout the event. As we reviewed the design with our subject-matter expert and project sponsor, new details would emerge with each iteration, but the overall theme and technical approach didn’t change much. Some details, we would learn, were critical to the project’s success.
By the time we adjourned late Friday night, we had (what we thought was) a complete and consistent view of our new app and its context. We would be building a mobile app that lets you pick legal forms, fill them out on your smartphone by using your voice or typing, and then have an officially formatted legal document mailed to you for the next step (e.g. review, submission to the court, whatever)—the app that would become known as The Court Whisperer.
Each of us had a clear view of our next steps. The developers were coding to deliver the app’s technical solution. Our team’s UX designer was mapping out various workflows and reviewing them with our sponsor/subject-matter expert, and I was preparing the story we’d tell.
I slept soundly that night, but had a design review going on in my dreams for the entire night. I actually solved some issues that were bothering me from our meeting. I’m not sure how that worked, but it did.
Saturday morning, I reviewed our idea with some law students and lawyers on other teams and unanimously, they understood the problem and how our idea would help. The validation was reassuring, so I began developing the pitch narrative. With less than five hours to go, we practiced in front of our first pitch coach. We were also fortunate to have a UW Law School Professor in attendance. After the pitch coach gave us some strategy pointers, the professor asked some pointed questions about our approach—identifying the potentially fatal flaw of being perceived to provide legal advice without a license. In an instant, we pivoted and our app became an icon.
Fortunately, this pivot didn’t affect our developers, but it confirmed the importance of reviewing the design with the target audience as early as possible. It also confirmed that a critical review doesn’t need much more than a PowerPoint deck and a whiteboard sketch (which is good, because that’s all we had).
Pivot and iterate
Based on the feedback, we revised our approach, built a new narrative, and practiced for another pitch coach. Her advice provided some fine points, which I took as confirmation that we were on the right track. She gave us some details to work on and, thinking I had a couple hours to go, I sat down to revise the deck. Somehow, in all the excitement of pivoting, I lost track of time (how embarrassing) and realized that we had only 57 minutes before the presentation.
Well that makes things simpler—we’re going with what we have. Period. In those remaining 57 minutes, we pulled together our final story, added the final graphics, and practiced about three or four run-throughs. As we were doing this, the developers we’re smoke testing the demo (it worked! Not too much smoke.) and we had it all together with, oh, at least 40-50 seconds to spare.
Showtime!
At the pitch sessions, I was impressed by the ground the other teams covered and the solutions they presented. Lots of talent had come together to come up with solutions for some difficult problems in a very short time. Our team was awarded first place by the hackathon judges, but there were many great ideas that could help many people have better access to legal services.
Taking my advice
I’d encouraged my students to attend hackathons as a way to get out and mingle with a purpose, push some boundaries, add some new connections to your network, toss another story onto your portfolio, and just come out a better person for having had the experience. However, I wasn’t really speaking from first-hand experience. Not that one needs to have lived all the advice they give, but it does add some credibility. Unfortunately, until recently, squeezing in a hackathon (or much else) wasn’t really a possibility as a doctoral student-husband-father-working professional. Now that I’m back to being just a husband-father-working professional, I have a few more available weekends than I’ve had for a while.
As luck would have it, I think I managed to accomplish all of the benefits I’d been citing earlier, so, I’ll repeat the advice with, hopefully, a little more credibility.
Attending a hackathon is a great way to get out and mingle with a purpose, push some boundaries, add some new connections to your network, toss another story onto your portfolio, and come out a better person for having had the experience.
Enthusiasm and dedication
Friday evening, we were strangers who had never met. The project sponsor had flown in from Washington DC, earlier that evening, just to be there for the event. While each of us brought something different to the team, we had enthusiasm and dedication in common. That was a very powerful combination, judging by what we accomplished in a short period of time. I can’t tell you how much fun that is for me to see—and how much more it is to be a part of. I saw the spirit in my trips to Honduras with IHS.
Keep your eye on the prize
(and keep reminding yourself what the prize is)
Or, forest, meet trees.
The real irony to me is while it’s called a “hackathon,” it’s really a “pitch-a-thon.” The judging was mostly based on the pitch/presentation we gave at the end of the event. That’s not to say there wasn’t any hacking going on, just that the hacking is a means to an end—and not necessarily the end that you might expect. The end is the demo. Period. It might look like the end is an idea, and you need enough of an idea and implementation fleshed (hacked) out to present a compelling demo, but the end goal is still the demo.
It can be very tempting to think that the end-result is an actual working product, but it isn’t. So get that idea out of your mind every time it tries to sneak in—and it will try to sneak in many times in many different ways. You must be ever vigilant.
In the grand scheme of things, the goal of the hackathon is to present a compelling vision for what you’ll do after the hackathon, when you can spend more than an hour designing a system architecture, more than 10 minutes designing a page of the UI, etc. Now that might (and probably will) require some hacking together of components in a way you’d never (I hope) think of doing in a production system—and that’s perfectly fine. The app/web-page, etc. has to only work one time during the demo/pitch. Working more than that and even working after the event is OK, too, but in this context, the primary job of your demo is to sell the idea during the pitch. Now, your mileage may vary, depending on the nature, goal, and sponsorship of the hackathon, but understand the goal going in, so you can stay focused on the way you want to come out.
Epilogue
Now that we’ve won, we’re not sure what the next step is. Our team, along with the 2nd and 3rd-place teams have been invited to another event in January, but as I write this, we (the participants and the organizers) are resting up and coming back to our normal lives, so I hope to have more to say about this in the near future. Our team members left with a lot of enthusiasm!
In closing, I’d like to thank the organizers and sponsors for putting on a great event with great food and facilities. Most of all, I’d like to thank our team sponsor Katherine Alteneder, and my fellow teammates Mathias Burton (UX designer), Dan Liebling (Back-end developer), Judd Deaver (Front-end developer), and Taylor Lea (iOS developer) for being amazing teammates!