On Wed, Aug 10, 2016 at 7:01 PM, Stephen Michel <stephen.mic...@tufts.edu> wrote:
Some great, intense, back and forth. I ask that Michael and mray pause
your discussion for a moment, because I have another perspective I want
to throw into the mix that may change the discussion somewhat and I'd
like to avoid you wasting time, but it might take me an hour or few to
get that written.

Alright, here goes. In short, we should use mray's version for MVP. Shortly after, we should add *in addition* Michael's version, heavily revised.

Mray is right that we need to provide two distinct representations to serve different use cases. But it's not simple vs complex. It's two different sets of information, each of which should be as simple as possible while still showing everything that needs to be shown.

I didn't realize the use cases myself until Michael identified them, though he may not have realized it yet. They are:

1. A history of *charges* (flow of money)
2. A history of *pledges* (history on our site)


1. Bob is dong his accounting. He checks his credit card / stripe history, and wants to know exactly what that charge is for. As far as Bob's credit card is concerned, May's pledge *doesn't* exist until July 1st, when June's pledge is fixed (though during the month of June, Bob may be interested in his outstanding balance). Bob's credit card also doesn't care about suspended projects; they look just like projects he's not supporting.

2. Alice is thinking about what software she uses in her daily life and whether she wants to start supporting any new projects, drop any old projects, etc. She wants to know what projects she's been supporting and for how long, whether she's ever dropped them, whether her pledge is successful in raising more crowdmatching funds or whether the project has stagnated with few patrons, etc. Alice is very much concerned with the difference between a suspended pledge and a dropped pledge, etc. She doesn't have a care in the world for whether a payout happened in March

Mray is designing for Bob and Bob alone. That's all we need for MVP, as Bryan tried to get to heart of. The only changes I might suggest (some already discussed) are:

- [Important] Add the date of charge. Bob needs the date of charge so he can cross-reference with his credit card bill. - [Important] Add what the monthly limit was at the time. Bob wants to verify that we didn't exceed his limit. - [Optional] Remove the number of patrons. Bob doesn't care about them, he cares about how much he paid. The reason we might keep this number is that WE want Bob to think and care about how big of a crowd he is matching. - Show this on the dashboard home page. By default, show only pending charges -- no history -- and the limit. At the bottom, have a "show more" or "show history" button to reveal previous months.

Michael is trying to design for both Bob and Alice. This would be the superior approach, if we were required to have only one view of the history. But we're not, so I think we should let mray's design serve Bob, and modify Michael's to serve only Alice.

- Remove any information about feeds, rollovers, and credit card charges. Alice doesn't care about those details. Basically, remove anything below "total pledge value this month" in your original mockup.
- Show this in its own tab.
- Include more visual styling to enable tracking a given project over time. Per-project coloration, a timeline view... things like that.

So far, there's been a lot of discussion about whether one set of goals are more important than another. I hope this email convinces you that both sets of goals are important and worth supporting (though only one is necessary for MVP), so you're now in alignment and can focus on the best way to support both Alice and Bob.

Design mailing list

Reply via email to