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:

• Slide show (hosted on SlideShare, of course) and podcast

Project Touchstones: How to Bridge Competing Viewpoints and Build Vision, Consensus, and Innovation / Jess McMullin

Monday, March 26, 2007

A key to working with business is to become a peer--design deliverables together.

Tools:

• Affinity diagrams—sticky notes
  With any data where trying to ID patterns
• Sketching with clients—conversational; use as a prop to articulate priorities (ask them to draw and then why did you draw it that way)
• Design the Box—design the elements of packaging (name, tagline, 3 key selling features, imagery/color/type; feature set)--helps to focus on the important
• Backcasting—start at ideal; what are assumptions and what has to happen—looking at dependencies/relationships; back to current situation
• Mental model/alignment diagram--lines up user activities with features of product--can build on wall with stickies

Principles for transforming from review/approve to working together
1. codesign—get over hesitancy of showing unfinished work
2. simple—should not have to be an expert to participate
3. concrete—sketching, sticky notes
4. flexible—should mean different things to different people; see technical and business implications in deliverables
5. evidence based—informed; secondary research (gender and video games); qualitiative research—looking at users in context
6. surface agendas—look for things that will; some things are easy to hide agenda behind; figure out how people really feel

Approach
1. getting people to work together—need to have the important folks at the table (ex: marketing VP); difficult to get them to commit
2. peel back the layers—get to agendas

• ask 5 why’s of any type: how is that important, why did you come, what do you hope to learn

3. partner, pilot, publicize—partner with influencers; small pilots; publicize the success; pulls in senior executives; need to have people there to “make sure you are doing the right job”

With sketching—can stay away from literal representations to help to remove from final product if people tend to get too committed to their view as final; stress at front that we will rip all of it up; emphasize that business skills is what is needed—not design

Consultant versus in-house challenges—point to processes already in place; then add the notions of codesign.

Application for L&ET:

• We have the perpetual problem of potential candidates for this type of thing with no time to participate. I think that if we went intense and made quick progress, that folks would be motivated to participate.
• Projects to try this one:
  o search box
  o room scheduler
  o Staffweb
  

Links for More Info:

• Slide show and podcast