Interaction design: (how) can we get more involved in some of the process?
asked 2015-05-01 20:27:40 +0200
Is there a way to be more involved in aspects of device (software) interaction design, so that when a new device or OS iteration comes out we can know better whether and why we want to buy, and so that we can know if and how our contributions may be improving things?
Wrt the overview info, examples, use cases and interaction-mapping directed graphs made available on this forum would help its users to file questions visually, in a way that would let the interaction design staff and code editing developers zero in more exactly on the issues raised and give better feedback, more clearly and faster.
Moreover, Duplicate mitigation could become part of the Question submission process. The Question's relation to the UI and UE for a specific use case or context and a related chosen step therein will help clarify similar and similarly-positioned issues, and allow Questions likely to be marked Duplicate to instead be automatically linked, and even combine votes for action to amend the common interaction step.
As I perceive it, that would be a better form of online community outreach, better for all related development work flows and better for marketing and sales. It is not just an issue of filing this under forum improvement. There are knock-on effects and all kinds of overworn clichés about virtuous cycles. Maybe this is worth a try. Striving to exceed expectations and demonstrably do so really do circle high above grounded talk of how difficult everything is.
We're here to help! Use what you've got, the work of six experts supported by the people you work for and by the people who bought a phone and think your work should be mostly directed by them.
Please no-one opine in an answer or comment, seriously or coyly, about how manual forum trawling and belaboured, repetitive, condescending rhetoric is somehow a more real or better dialogue than one supported by automation, visualisation, and distraction reduction.
Maybe you can bring this up in a community meeting at some point. While the design team reads they don't participate much in TJC. There you will get an answer and maybe a solution on how to make community contribution integrate faster with upstream (not only for UI/UX stuff but code also).
Of course design cannot please everybody and someone has to say no at some point but discussion never hurt anybody.
ApB ( 2015-05-01 21:48:40 +0200 )editI'm glad for your comment. However, even if the design team's participation on this forum is passive, I still strongly feel best able to contribute to discourse and testing via documentation. Interested parties can then review results at their discretion.
That the team sees the forum is, to some extent, an argument for making its perusal more immediately and actionably useful.
Doing it by documentation validates a documented approach to solutions more, to do it with documents than also via meetings. I mean no disrespect but I wish to convey that my opinion (and experience) is this: reflection and carefully considered feedback is much harder in a meeting when a lot is at stake for all attending stakeholders, and all in an arbitrarily short space of time. I feel less gets done that way.
Above all, it is much simpler and easy for me to participate here, when I can. Unpaid meetings are on a completely different scale in terms of dedication; where performance, expectation and reality very rarely converge.
rdmo ( 2015-05-01 22:41:20 +0200 )edit