Not Invented Here syndrome (NIH) is the guilty pleasure that tempts engineering teams into creating bespoke approaches to problems that have already been solved. Even having your eyes opened to the temptation doesn’t immunize you from it. So, how do you know whether a bespoke solution warrants the effort or if it’s just plain hubris?
Alley first got to know the Society for News Design earlier this year when we sponsored their annual conference in Washington, DC – where Brad Campeau-Laurion shared some hard-won insights about designing with development in mind. So we were excited to participate as a host of this month’s SNDMakes prototyping workshop in Austin, Texas.
The event format was basically a hackathon, but without any pressure to stay up all night. Leading up to the event, organizers assigned the attendees to teams and introduced us all via Slack. So when we arrived on Friday morning at the Austin American-Statesman, we could jump straight into planning, designing, and prototyping an answer to the question:
“How might [media organizations] design tools that build community?”
That’s a big question! Fortunately, my Team Silicon Hills teammates were up to it: Aidan Feay from Vox, Sydette Harry from Mozilla and the Coral Project, and Ashlyn Still from the Atlanta Journal-Constitution. Here’s how it went.
Our first step was to establish the rough outline of a process for the weekend. We went through these steps.
Define our terms – what “community” are we talking about? What are some features of the kind of community that we seek to build?
Look for inspiration – what organizations (media or not) are building community in ways that we admire?
Narrow our scope – what problem do we want to focus on?
Create user scenarios – in the community we’ve defined and for the the problem we’ve identified, who would use our product and why?
Translate scenarios into product – what design and technology assets would be required to pull this off? What’s the business case for it?
Poke holes in it – why is this a bad idea? What can we learn from those objections to improve our concept?
When it came time to report back to the group on Friday afternoon, we had an idea. Within the team, we had a clear sense of user experience, features and technology, how it could make money, and why a publisher would want to install it on their site. We did not have a polished description, mockups, or a line of code written.
Walking around the room on Saturday morning, it was clear that other teams were pretty deep into prototyping, which we had yet to start. But at least our plan for the day was simple.
Architecture and wireframing
Build prototype for Day 3 demo
I’ll be honest – by mid-afternoon, I was pretty nervous that we were just getting started with the actual coding. But once we had a framework in place, things came together very quickly.
With just a couple hours on Sunday morning before presenting our demos, we worked simultaneously on two tracks:
Creating and practicing the presentation
Refining the prototype
In the end, I was really happy with our results. Our approach differed from most teams (some of whom had to reboot entirely), but we ended up with a strong case for our idea as a realistic solution and enough of a demo to get the point across. And it was a great way to reinforce a lesson that’s easy to overlook when you’re feeling the pressure to jump right into making:
Measure twice, cut once.
By the way, here’s what we made:
Meet Converge. Converge is a news utility that connects communities through their interest in local content. Users can see what topics matter most in their communities, make connections, and gather resources to further their involvement. Participants in Converge form organic, physical communities for offline connection and provide publications with valuable information on what shapes their environment.
Our demo included these steps:
A reader can express their interest in a topic by clicking the Converge icon in a local news story.
The topic view shows where they can find out more about local events and community around that topic.
An organizer, e.g. a city council member, can use this view to see what’s happening in their local area for different topics and events.
Or they can become a community resource by organizing an event.
Any user can see their event and topic participation in the dashboard.
Although the example is about civic participation, Converge would be just as applicable to local arts, entertainment, or sports. And it works two ways – you can encourage local organizers to create events by showing interest in a topic, or promote an event that you’ve already created to people who are interested in the same topic.