Design Story
Recently I have taken part in DEV Challenge 12 competition. The task for the 1st round of the competition was to redesign existing mobile app for Photofact.info project. So, the case study described below is based on this task and helped me get to the 2nd round with the 7th place out of 55 participants.
Since the original app and the system are indented for Ukrainian/Russian speaking audience, Russian language was used as the app UI language and for the description.
Challenge
Redesign existing mobile app for Photofact.info project.
Approach
In order to optimize the redesign process, define key problems and come up with optimal solution, I decided to pick up some activities from Design Sprint framework by Google Ventures.
Ask Experts
Since I didn’t have the chance to talk to real experts, I used the brief attached to the task as a source of knowledge about the startup and the mobile app. Based on that, I built the hypothesis about project goals, users and roles etc.
Map & How-Might-We Questions
Based on the data acquired earlier I drew a map for key roles of the system. Then I complemented the map with “How Might We” questions, which helped to shift attention from having problems to identifying opportunities.
Long Term Goal
To stay focused during the design process, be able to align the vision and adjust the solutions, I stated the Long Term Goal, as a summary of all insides that were gathered during the Ask Expert Activity.
Lightning Demo
Before jumping into idea generation I reviewed several similar apps, and some features from apps that solve similar problems but in different business areas.
Notes and Ideas (4-step Sketch activity)
Notes and Ideas activities aims to sum up all the insides gathered before. It is quite right time to ask additional questions as well as generate first ideas.
Crazy 8s (4-step Sketch activity)
Even though the Crazy 8s exercise does not lead directly to the solution creation, it helps free imaginations from judgment and speed up the idea generation process. To do so I picked up one idea “how list of tasks could be presented “ and drew it 8 times within 8 min — 1 min for each iteration.
Solution Sketch (4-step Sketch activity)
Based on previously gathered ideas, I created a paper sketch of the very first concept. The main focus was made on the role Reporter and the corresponding task “Make and send a photo report. The flow should be as simple, intuitive and understandable as possible, since it is going to be made by taskmasters, workers, car drivers, cleaners etc.”
User Test Flow
Before diving into prototyping, I had built a sequences of steps for the role Reporter, that should be taken for accomplishing the given task within the app. Later, this journey served as a base for creating further mockups .
Prototyping
Having the Main Concept and User Test Flow at hand, it was pretty easy to start creating the screens.
So, let me quickly walk you through the screens.
I assumed that users with role Observer are plain city dwellers so they cannot become Reporters and accomplish tasks until they work for a specific organizations. Whereas, Reporters are workers who, potentially, might be Observers, but they have enough their own task to be done. That is why the cases of switching between roles are rather rate. Based on this hypothesis, I created a bit different UI for each role.
The first screen that a Reporter sees is the map which shows all objects assigned to him, where the ones with the tasks are colored according to their urgency. In order not to overload the map with color-coding meaning, I added the legend which can be closed once info is learnt.
The list of tasks is also available from the menu section. To make the user interface more intuitive for target audience, I used, whenever possible, full text labels for links and buttons instead of icons.
Once the problem mentioned in the task is solved, Reporter creates a report which might include multiple photos and a comment. Creation date and coordinates of a photo are generated by default.
To the report, a photo might be created on the fly or added from the device gallery, if the photo coordinates match coordinates of the reported object.
To make it visible where the problem was and what exactly was fixed, specific spot might be highlighted on the photo.
Once sent, the system will notify Reporter that the report was sent successfully and navigates him to the list of his reports.
In addition, Reporter can access list of reports from the corresponding section of bottom bar and check report statuses.
When there are two roles available for a user — Reporter and Observer, he can go to Profile section to switch between roles. For example, the user selected role Reporter to accomplish tasks assigned to him and later came across some problem he wants to notify about. However, as I mentioned before, according to the initial assumptions, it is rather rare case.
As I mentioned before, user interfaces for roles have some differences. For example, Reporter is able to see only objects assigned to him, whereas Observer is able to see all objects or notifies about a problem for a new spot.
Testing
The destination point of the activities described above was user testing. Even though it was conducted only with one user, it helped to reveal major problems. For example, it was clear that a user did not read what was written on the very first popup with roles description. That was why she could not switch between roles later. See detailed report below.
Takeaways
Thank you for reading! You are highly welcome to share your feedback and ideas.
