Wednesday, May 23, 2007

Fast, Cheap & Somewhat in Control: 10 Lessons from the Design of SlideShare / Rashmi Sinha

Monday, March 26, 2007; Closing Plenary

Creator of MindCampus (user experience research product) and SlideShare (shared space for slideshows) shared insights on application development and IA.

Observations on current web:
  • Agile development is part of Web 2.0.
  • 1st generation—sharing without context
    2nd generation of social networks—connect over objects (photos, question)
  • Users drive navigation; Let good content rise to the top

SlideShare

  • “myspace for over 30-yr olds”
  • will be adding audio soon
  • some are using as courseware
  • Will be releasing API

Approach to developing SlideShare:

  • Create and get feedback afterwards; get answer to the real thing.
    a. Needed to see in use to understand use of the social system.
    b. Don’t have the tools to anticipate social system
  • Don’t need personas when social software users pound you with advice.
    a. Customer service as user research; monitor blogs/rss
  • launch first, refine later
    a. don’t over-analyze
    b. look at best practices, make a guess
  • constant connection with users by monitoring activity and other informal ways; whole team responds to issues that arise.
  • designer-developer role in the team allowed for easier communication—less need for design artifacts; hybrid roles are more common in small teams
  • under invest in visual design—let users feel ownership of space; users less afraid of messing it up
  • Focus instead on making the app as fast as possible.

Much of this approach is surprising and was experimental (seeing as she first developed a product to assist in user research). Through this development, she discovered:

  • you do need to do user research when feedback “becomes a torrent”
    Too much input, then you can’t process.
    Need to decide who you are building for
    New team members need summary info
    Need to improve beyond “low hanging fruit”

Possible application to L&ET:

  • What tools do we provide that could be useful in a "mashup?"
  • How do we staff support for the apps we’ve built?

Links for More Info:

No comments: