Clients who used our geofence uploader expressed the need to be able to upload multiple geofences at a time from a csv file. After exploring multiple different ways of displaying error and success messages we landed on a simple but effective design.
I lead brainstorming sessions, conducted competitive research, outlined the userflow and did all ui and visual design work. I reached out to other designers not on the project for feedback as well as user-testing.
The previous options for handling geofences allowed users to upload geofences individually or programatically change multiple geofences via API. This left a gap for non-technical users with large numbers of geofences. Clients expressed their frustration through feedback and specifically asked for a middle ground.
A large amount of internal research was done for this project. After acquiring a company last year, Foursquare's dashboard design was not as tight as it used to be. Different brands and different interactions etc. made for a disjointed experience. Although this project wasn't addressing this problem, it was something that had to be taken into account in order for the user to have a good experience.
I explored multiple different ways of displaying feedback: returning a csv file with the errors directly in it, displaying the errors in a table, displaying just an error message telling the user they needed to upload a new file. After speaking with the developers on the project, I learned that we didn't have the ability to return a csv file. This was my preferred option, it would have allowed the user to do all editing within the file. This way, they wouldn't have to go back and forth between the browser and the csv file (and the fact that the dev console is not responsive makes this type of work even more frustrating). After backing up a step and doing a bit more research, I landed on a middle ground that was easy to implement on the dev side and created a better user experience.
Instead of returning a csv file with errors in it, I proposed we display an error message and allow the user to open a new browser window with a responsive error table. This got around the browser responsiveness problem and allowed the user to resize the window so they could view the errors and make changes to the csv file at the same time.
Handoff to the dev team as well as user-testing after implementation are the next steps. One of the main things I learned during this project was to include dev in the planning process as soon as possible.