+1 for lots of quick iterations.
At 8:22 PM -0800 11/9/05, Philippe Bossut wrote:
Hi,
I think the process (as in set of steps) is workable. I'd advocate
though to have a short feedback loop between steps 2 and 3, i.e.
mock up or prototype 5 ideas or more and iterate through the
discussion.
My experience is that it's very useful to show lots of design and
variation rather than few so that people can break the design apart
and articulate what they like better. Having to choose up front
between 2-3 designs, people tend to compromise on stuff, sometimes
just to get their pet ideas in. At that stage of the process though
(stage 2), I think we should still be open to discuss everything in
the design.
One day, I created 10 variations of a main screenshot for an imaging
app (which didn't see the light of day but that's another story...),
did color prints and pin them in the hallway, asking people to vote
and otherwise interviewing them whenever someone would come by. It
was incredibly efficient.
Cheers,
- Philippe
Sheila Mooney wrote:
Due to the high volume of traffic on the design list lately it's
likely that not everyone has seen this or had a chance to read it
yet (with all the bug fixing going on etc). We haven't received
many comments so far and we wouldn't mind getting some feedback
from the developers on this process.....when you have a chance to
since I know you are all busy.
Thanks,
Sheila
Begin forwarded message:
*From: *Mimi Yin <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
*Date: *November 8, 2005 11:48:38 AM PST (CA)
*To: *Chandler Design list <[email protected]
<mailto:[email protected]>>, OSAF Development
<[email protected] <mailto:[email protected]>>
*Cc: *Lisa Dusseault <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>, Sheila Mooney
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>,
Katie Capps Parlante <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
*Subject: **Processing Dogfood Feedback*
Pre-0.6 Dogfooding has uncovered some important design issues
which has in turn prompted quick responses that will make it into
the 0.6 release. All in all, it has been a successful experience
and a great opportunity for us to figure out how to deal with
Dogfooding feedback once 0.6 is released for real. This in turn
has prompted further discussion about refinements to the feedback
submission process.
Given that code freeze for 0.6 is nigh and available resources are
as always scarce...here are some guidelines for submitting
feedback.
1. Is this something that prevents you from Dogfooding Chandler
calendar in 0.6? (Helps us prioritize.)
2. Is it an "I can't understand this!" issue OR "I can't figure
out how to do this!" issue OR "This is really annoying!" issue.
3. Lastly, some ideas for possible solutions.
Suggestions for solutions are more than welcome, however, it is
important for the group to have a shared understanding of the root
of the usability problem (which is why I have put it as a #3).
Some solutions are not available to us either because they are too
expensive to implement in the short-term or destabilize other
areas of the design. If we can all come to an understanding about
the problem we need to solve, we'll be much better equipped as a
group to brainstorm solutions that work within the context of the
both design and development realities.
Hopefully most feedback will be fairly straightforward, but once
in a while, design issues will arise that require further
exploration. We would like to experiment with more collaborative
approaches to dealing with such design issues. Our branding effort
for 0.6 was one early foray into distributed, collaborative design
and we're looking to incorporate this approach into our core
design process.
This is not something any of us have done before (if anyone has
done this, please speak up share your experiences!), so apologies
in advance for changing the rules mid-stream or making up new ones
as we go along. This is going to feel a little like Calvin-ball at
first. http://www.geocities.com/SoHo/Nook/2990/cb_rules.htm
Here's a strawperson proposal:
1. Brainstorm of ideas for solutions. At this stage, we will try
very hard to avoid evaluating solutions for feasibility or even
usability.
2. Once a critical mass of ideas have been submitted*, we will go
through a process of whittling it down to a set of 2-3 options.**
The whittling down process consists primarily of:
a. Evaluating how well the proposed solution fits into the
existing design framework AND/OR
b. Considering whether the fix is important enough to merit
re-examining larger design issues.
c. Evaluating the feasibility of the proposed solution and
estimating how much time and resources it will take to implement
3. Mock ups or prototypes of ideas.
4. Informal usability testing as appropriate to the design issue at hand.
5. Presentation and analysis of results.
Steps 1-5 could all happen within a single day or over a period of
a few weeks. It could happen several times over the course of a
week or a month. It all depends on the scope of the design issue
how ornery the problem is.
Feedback and comments welcome!
Mimi
* Brainstorming never ends per se, but at some point, we will need
to open up the discussion to evaluation and prioritization.
** Step 2 will be the hardest to do well and potentially full of
pitfalls. We're doing a lot of hand-waving about it right now.
We'd like to see how things work themselves out naturally and
impose structure only on an as-needed basis.
------------------------------------------------------------------------
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
