> Hi Bjorn, > > I do share your concerns, but would like to present a somewhat even more > radical position. > > As I understand it, you advocate for an evidence-based decision-making for > design questions. > Anyone can come up with his/her design alternative. > Eventually all the alternatives will be tested by actual users, in one > survey or another, and may the most popular alternative win! > > I would like to ask why not have a preliminary set of surveys, to identify > the needs and likes of actual users and of potential users, > and then come up with design alternatives that address these likes and > needs. > > What do you say? > > dror > > -- > View this message in context: > http://nabble.documentfoundation.org/The-future-of-design-suggestions-tp30 > 85560p3092867.html Sent from the Design mailing list archive at Nabble.com.
I'm with you on the warning about premature GUI design proposals. My experience is that Use Cases are amongst the premier means to capture requirements. (I'm not convinced Agile, with user stories would work in a Libre Ofice context) I operate a UCD process that iteratively gathers requirements in Use Case form, validating them with stakeholders. When I have sufficient confidence about a use case or related set, I start paper and pen architectural designs and wireframes and again, iteratively validate them. As the iterations proceed towards higher fidelity prototypes, including some that test interaction behaviour design, I again make the call and if I'm confident the design is sufficiently coherant and addresses the original validated use case, the prototype gets hardened to implementation, which is once again validated with the stakeholders and their use case(s) As I said, in my reply to Scott's Design Tennets Proposal, "I couldn't agree more with the proposal that we should be guided by principles. What I have found a little frustrating, by way of comparison to the developement of commercial software is the disconnect between genuine user requirements and development. What I think is consistently missing here is the next layer down from your excellent 'tennets'; user validated requirements (not personal opinion or anecdotal observations). A corpus of well structured use cases, including those for the product architecture, will help us set a strategic direction. We should research requirements before too many folk pitch in with alternative designs and prototypes that may or may not be any kind of solution to users' real needs. It is precisely this which will make or break Libre Office and will set it apart from other office software. If we know what users want then we can stage implementation in deliverable chunks over several releases. There's no need to implement the whole deal in one hit. One final thought. If the current implementation or architecture is part of an impediment to realising a long term roadmap to a redesign, then that too should appear as one of the tennets." Cheers, Greg -- Unsubscribe instructions: E-mail to design+h...@global.libreoffice.org Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/design/ All messages sent to this list will be publicly archived and cannot be deleted