Helping Non-Techies and Techies Collaborate to Make Great Software

Dan Newman, MAPLight

Dan will discuss the MAPLight approach to software design. With processes that utilize drawings and mockups, he'll demonstrate how colored pencils, a scanner, and a good graphic designer can help non-techies and techies build successful software projects.

Session Notes

• Doing an intro to Maplight
• Go round of who you are, org, role, and what you want to solve
  • Dave Greenberg, CiviCRM, increasingly get large numbers of requests from our user base, and we try to engage them to deepen the request beyond a sentence. More effective ways to deepen the conversation, online.
  • Sarah, American Academy of Opthomology, Manager. Good bridge between technical and non-technical people, but we're doing a huge redesign of our website and trying to find better ways to communicate about that.
  • Skip, United States Institute of Peace, Improved communication is what
  • Mark, Independent developer, getting more used to agile methods of putting everybody together in the same room, but I'm still struggling with doing that online.
  • John, Agitpop, new media content and tools, popular agitation -- totally non-technical person in a technical world. I like to hold the non-technical place in the room.
  • Mark, Open Planning project, lead developers, technology-focused nonprofit. See what other ideas or approaches might be out there.
  • Jim, Chicago Tech cooperative. I feel pretty good as a project manager, being able to translate geek-to-english and vice versa. Would love to know more about online stuff.
  • Ross, Independent developer. Telling my mom about twitter, I found Common Craft who does animations of web-2.0 stuff. Found it inspiring.
  • Ernie, Smart Voter, involved in enhancing this service and also add on some tools that support conversations. Also interested in remote issues.
  • Colin, Quilted, we do sites from start to finish, our backgrounds are in design. We do the tech side from the design position. Figuring out how to manage that limbo.

• Roundup
  • Tech/non-tech how to communicate better
  • How to handle user requests

• Daniel: First did stuff in Visio, but have moved to doing things on paper
  • Side benefit: letting all staff participate
  • We split this into two parts: design, and programming
  • We give programmer a mockup, plus a 2 page list of behavior focusing ONLY on what is not obvious.
  • Then there's some iteration with the programmer and questions.
  • By the time it's done, the mockup is pixel perfect.
  • This is passed off to a project manager, who knows the data well.
  • We use Basecamp for threaded conversation and shared files
  • Everything starts with a sketch, and it takes many many drafts (maybe 5 or 6)
  • Use colored pencils, it helps differentiate information
• Design stakeholders
  • Lead designer
  • Constituents
  • Graphic designer (off-side contractor)
• Weakness in the system, is getting constituents input. We're planning on showing things to constituents
• Beneficial side-product is that the UI is done way before the development is done
  • Much easier to build support if you can show people what it's going to look like. Can't overstate how important this is.

• What works for people?
  • Have you ever done user-testing? Best practices: They should be alone. Check out Silverback (http://silverbackapp.com) for Mac. User testing is another loop.
  • How do you get users?
    • We just put the word out. We have the luck of having some UX people on our team. User testing while you're watching them is better than nothing. Give them some tasks. Watch them fail.
  • Sarah: We did a user-test. We gave people $50 to come test, and had cameras up. We also did a card sort of types of content.
  • Dave: We were designing a broadcast mail tool, we had a user session where we sketched out a few different ways for the flow to go, and asked them to pretend to go through them and see what happened.
• Jim: How do you prototype? Do you start with design or programming? We do functional prototypes that are just black and white wireframes with full functionality. And we won't do the design until that's done.
• For us, there are more than just design and programming, there's usability, interaction design (UX), front-end development, back-end development. Start with "what do we need this thing to do". Then once we have that set, we'll go off and do some sketches.
• Dave: For us, it would be helpful to have tools to capture pictures from our users.
• A tool: Skitch.
• Other online ways of getting feedback? User feedback comes late in the cycle. Though education of users is helpful.
• Jim: Chicago Technology Cooperative, we're actually starting a mandatory 1-day orientation for clients.
• Daniel: Mind-mapping software can really help. For any kind of new project or new feature, you can mind-map it
• Agitpop: Can you use that remotely?
• Daniel: We use go-to meeting and have everybody sharing the screen.
• Dimdim - open source web conferencing solution -- screen sharing, conference calls
• Do other people do functional testing? Like selenium and windmill. We use Twill. It's valuable, but it's an up-front cost.
• Talking about functional testing frameworks. Talking through them:
  • Twill
  • Simpletest plus a Drupal module to do functional testing

Take aways

• Drawing pictures is good and allows non-techie people to be involved in a design process
• Using a digital camera and taking snapshots can work great
• You can do user testing without a computer
• User testing is important

Links

• Silverback Guerilla User Testing app for Mac OS X - http://silverbackapp.com