<div dir="ltr">Hi all,<div><br></div><div><br></div><div>this is an interesting discussion. I've been in a team doing practical design and user research work with <a href="https://projectsbyif.com/clients/" target="_blank">ProjectsbyIF</a> in this space. The work was not specific to OSM, but included multiple digital services that included mapping data and were offered globally. I've also done work on feedback/change loops for address data.</div><div><br></div><div>Some hopefully helpful thoughts based on that experience:</div><div><br></div><div>1. The benefits of end-end feedback/change loops are potentially enormous.</div><div> 1.1. To users, to service providers, and to foundational data sources - like OSM.</div><div> 1.2. For service providers the issues and benefits are wider than mapping data</div><div><br></div><div>2. The UX challenges are surmountable but, if you want to reach the global use base of end service users, broader than some might think </div><div> 2.1. Elements of OSM data appear in many, many services each with their own users and expectations<br></div><div> 2.2. Compare the users, user journey and interface in a dedicated mobile mapping app, to a desktop mapping app, to an address entry form on a delivery service, or an application for welfare benefits</div><div><br></div><div>3. In user research we could see that digital service users want to see that changes are received/actioned</div><div> 3.1. Expectations about timescales can be managed through design and through features that allow users to track how their changes are handled.</div><div> 3.2. The design for change tracking would need to be different in, say, an OSM native app to, say, a mobile mapping or delivery service</div><div><br></div><div>4. In user research we could see that digital service users were more likely to provide changes if they could see that other people like them were doing the same.</div><div> 4.1. This leads to work in UX design - eg giving visual cues that changes are happening at places where people might want to suggest changes - but also in designing features that help communities form and people work together to provide and agree changes.<br></div><div> 4.2 I know OSM has some of those capabilities within its setup, but there are also communities within the user groups of the service providers that use OSM data.</div><div> 4.3. It is possible to support communities to form at those different levels of both digital services and OSM, but those will need to be designed to be meaningful to those different user groups/experiences</div><div> 4.4. This would allows communities to raise changes about and reach agreement on things that matter to them - eg some people and communities might care about individual address data, others might need to reach sufficient consensus on the placename that displays at a particular zoom level within a particular service, &c.</div><div> 4.5. This is an area where the OSM communities will have more experience than most digital service providers :) </div><div><br></div><div><div>5. The 'back-end' product and data teams in service providers want change data to be structured. This will ease their analysis and validation, but needs contextual design.</div><div> 5.1. The design for that UI and structure needs to consider the needs of end service users as well as data users</div><div> 5.2. Too much structure will create friction that turns off end services and doesn't align with the goals of digital product teams by reducing use/adoption, too little won't work for data users.</div><div> 5.3. If they can see a benefit for them then service providers will analyse, enhance and validate the changes before providing it back to a source, like OSM. (Some providers already do this)</div></div><div><br></div><div>6. There are some general design patterns and principles about how to build these change loops through the <a href="http://sarah-drummond.com/full-stack-service-design/" target="_blank">full stack</a> from users/UI to service providers to OSM.</div><div> 6.1. Those patterns/principles are not well researched or known</div><div> 6.2. Design patterns and principles is a language that product teams in large digital service providers speak and respond to</div><div><div> 6.3. Large service providers compete over those patterns, so have internal work that is not publicly shared. Think of the equivalents of <a href="https://developer.apple.com/design/resources/" target="_blank">Apple's design resources</a> or <a href="https://design-system.service.gov.uk/" target="_blank">government design systems</a> that go deeper than UX all the way through to back-end data sources and provide evidence that help product teams make a decision on which pattern to use for a particular product or service</div></div><div><br></div><div>7. Designing, testing and publishing openly licensed patterns/principles would be a good way for OSM to reach those product teams and create that impact.</div><div> 7.1. Design patterns/principles is the kind of thing that could be on a strategic plan</div><div><br></div><div><br></div><div>Hope useful,</div><div>Peter</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 19, 2023 at 11:47 AM Christopher Beddow <<a href="mailto:christopher.beddow@gmail.com" target="_blank">christopher.beddow@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Brian I think you have a good summary of a user journey here, but I would not say it's even the map editing being intimidating (it can be and if you ask friends and family even what I think is well designed in iD/Rapid could be construed as impossible to understand by someone else), but I think it can also be a level of effort. I am not very motivated myself to fill out surveys or leave reviews when I am traveling, only in exceptional cases. But quick reminders to do a rating or confirm something are low effort and I go for it. <div dir="auto"><br></div><div dir="auto">Again, Google is very good at this. Airbnb, Über/Luft, and Booking are good at it lately, by prompting users to only spend 30 seocnds or less providing info like "did this accomodation have all soap and shampoo you needed?" or "what did you enjoy about this taxi ride (pick options like clean interior, friendly driver, good driving, etc)". </div><div dir="auto"><br></div><div dir="auto">As somebody who loves editing the map, having hints like these given to me as raw material, especially aggregating as "insights" (which I would love to hack on as a data engineer), would be a gold mine of good information to enrich areas. Lower effort can mean lower quality, but higher volume, and often converge to some valuable consensus information. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 19, 2023, 11:49 Brian M. Sperlongano <<a href="mailto:zelonewolf@gmail.com" target="_blank">zelonewolf@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 19, 2023 at 3:34 AM Alexander Heinlein <<a href="mailto:alexander.heinlein@web.de" rel="noreferrer" target="_blank">alexander.heinlein@web.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What is worse, having (almost) no user feedback or having more user feedback than we can handle (today)?</blockquote><div><br></div><div>Think about it from the perspective of an ordinary user of an app, that knows nothing about map editing and isn't one of us map nerds. Somehow they learn that OpenStreetMap powers their app and they head over to our web site to see if they can fix whatever problem. They're intimidated by the idea of editing a map, think it's too hard, but instead see that there's this note option. So they leave a note, explaining that such and such is wrong. However, nobody looks at the note for months or even years. All the user understands is that "they reported the problem to the open street maps people and nothing got fixed." Now, I don't have the statistics to say whether what I described is more or less common than someone's note getting resolved quickly, but I could absolutely see "too much feedback" being just as harmful or worse than not enough.</div></div></div>
_______________________________________________<br>
osmf-talk mailing list<br>
<a href="mailto:osmf-talk@openstreetmap.org" rel="noreferrer" target="_blank">osmf-talk@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/osmf-talk" rel="noreferrer noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/osmf-talk</a><br>
</blockquote></div>
_______________________________________________<br>
osmf-talk mailing list<br>
<a href="mailto:osmf-talk@openstreetmap.org" target="_blank">osmf-talk@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/osmf-talk" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/osmf-talk</a><br>
</blockquote></div>