[Osmf-talk] Applications creating notes

Fri May 19 11:31:03 UTC 2023

Hi all,

this is an interesting discussion. I've been in a team doing practical
design and user research work with ProjectsbyIF
<https://projectsbyif.com/clients/> 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.

Some hopefully helpful thoughts based on that experience:

1. The benefits of end-end feedback/change loops are potentially enormous.
            1.1. To users, to service providers, and to foundational data
sources - like OSM.
            1.2. For service providers the issues and benefits are wider
than mapping data

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
            2.1. Elements of OSM data appear in many, many services each
with their own users and expectations
            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

3. In user research we could see that digital service users want to see
that changes are received/actioned
             3.1. Expectations about timescales can be managed through
design and through features that allow users to track how their changes are
handled.
             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

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.
            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.
            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.
            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
            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.
            4.5. This is an area where the OSM communities will have more
experience than most digital service providers :)

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.
            5.1. The design for that UI and structure needs to consider the
needs of end service users as well as data users
            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.
            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)

6. There are some general design patterns and principles about how to build
these change loops through the full stack
<http://sarah-drummond.com/full-stack-service-design/> from users/UI to
service providers to OSM.
            6.1. Those patterns/principles are not well researched or known
            6.2. Design patterns and principles is a language that product
teams in large digital service providers speak and respond to
            6.3. Large service providers compete over those patterns, so
have internal work that is not publicly shared. Think of the
equivalents of Apple's
design resources <https://developer.apple.com/design/resources/> or government
design systems <https://design-system.service.gov.uk/> 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

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.
            7.1. Design patterns/principles is the kind of thing that could
be on a strategic plan

Hope useful,
Peter

On Fri, May 19, 2023 at 11:47 AM Christopher Beddow <
christopher.beddow at gmail.com> wrote:

> 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.
>
> 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)".
>
> 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.
>
> On Fri, May 19, 2023, 11:49 Brian M. Sperlongano <zelonewolf at gmail.com>
> wrote:
>
>>
>> On Fri, May 19, 2023 at 3:34 AM Alexander Heinlein <
>> alexander.heinlein at web.de> wrote:
>>
>>> What is worse, having (almost) no user feedback or having more user
>>> feedback than we can handle (today)?
>>
>>
>> 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.
>> _______________________________________________
>> osmf-talk mailing list
>> osmf-talk at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/osmf-talk
>>
> _______________________________________________
> osmf-talk mailing list
> osmf-talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osmf-talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/osmf-talk/attachments/20230519/9fe77b10/attachment.htm>