Monkeynotions

Hi All!
I went to dCamp this weekend and took some *rough* notes from *some* of the sessions. I took rough notes of the following sessions:

Tools Designers Use
Powerpoint
Powerpencil
Omni-Graphyl
For siteMaps, I’ve heard of iRise, full dev and rough prototypes upfront. You can do serverside includes, it does have ability to map out all the pages.
Who is your audience? No text, lot’s of pictures. Need to make documentation usable. Designing your process. Talk to your users/developers about what they need from us. Try something new, and walk over. Be proactive about what is helpful for them? What tools have worked for you in the past. How do you work collaboratively? Go over stuff in meetings and what kinds of things do they need? What it turned out for her was UI Patterns? There was a bit of then designer trying to understand what they say. Designer was given the lattitude to learn that.

Is there anyone in the room that works in code prototyping? Ruby on Rails is the economic example. You can prototype interaction. The prototype becomes the building of the application.

AJAX Design, Dev & Usability

Tension b/t Design & Dev.
Understanding users is too slow. In contrast usability, agile approach were working in low

levels of agility and research didn’t map onto breaking down.

GOOG Dev
They have been doing traditional usability testing
Instant Messaging link b/t researcher and the prod team next door to empower the team, and make usability into a collab activity. Dev has been making changes to the product during testing IA is bottleneck

Traditional Agile Approach they would have went into lots of problems (BIRT Case Study).Before you do Agile, do your research.Have a holistic design. One that can use engineering, done and then backlog them. Entropy reduction. Some area will be touched several times.

Improve things that are already existing.

AGILE Community didn’t address the design, do a quick first pass. Doing design takes time.

UPFRONT RESEARCH AND GRANULAR DESIGN FIRST!! THIS IS TRUE OF ENG TOO..
(e.g. Architectural Design)

Discovery Stage=arch + ui experience is a lot of stakeholders

During Design Meetings, so many competitng priorities, trying to let that first meeting
evolve as it does, let 1 wk to mull and re-visit and re-meet. Very hard to do in giant planning sessions. Level of trust, better sense of ..

Everyone has a set of cards and everyone puts up an eng tasks, then everyone put on a
number of how long that task will take, and if there were outliers then they explain. Then
you can see how long it is. This is good for understanding different roles (e.g. if dev thinks it will only take 5 hrs to do UI and UI thinks it will take 20 hrs to do it, UI explains theiroutlier)

Time boxed sprints … date driven, specific time frames that will end on time.
Backlog=Requirements

All engineers will look at competitive research. Personal ownership/investment.research sprints, doing some prototyping. parallel work. Building backend elements.

Stickies. What’s in backlog, on task. We go thru stand up meetings, and just move stickie around. PjM counts burndown. BURN DOWN GRAPH. Logical units measured. Product Backlog is owned by Product Management. Instead of an MRD, Don’t think of releases is future releases. Marketing is the owner. They are the priority owner in this backlog. PM decides what slips and what doesn’t.

More notes that people took can be found here.

This entry was posted on Monday, May 15th, 2006 at 10:14 pm and is filed under conference. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.