Maps.io

 

Maps.io is a personal project for a concept I’m pursuing. In this project I’m showcasing my UX workflow and how I move from my problem to an objective. Below I am showcasing many of the practices and tools I use when thinking through an application. These practices assist me in properly defining, organizing, analyzing, and capturing the needs I desire to be meet for the project.

Maps.io is an application for users to share something like a personalized mixtapes of locations instead of songs. Through the app users will be able to better find new spots in town and the system will help users to save their finds for future visits. The interface is centered around the map to encourage users to explore and try new things.

UX Workflow

My UX workflow can change drastically project to project depending on the objectives and needs of the assignment. Here are some of my most commonly used practices in the context of Maps.io…

  • I start by collecting as much information as possible on the product that is desired. I then create a mind map. Mind maps help me to quickly jot down my thoughts and ideas and allows for stream of consciousness.

  • I first determine who are my users, and how many user groups are interacting. Determining my set of users allows me to then focus on collecting current user frustrations and and desires from each group. I do these through two means, empathy mapping, user shadowing, and persona development…

    Empathy Mapping: This practice allows me to quickly think through the users actions, thoughts, feelings, and sayings. This also helps to define the world in which my users live.

    User Shadowing: I shadow users whenever and however possible to get a grasp on what the product needs to improve from. it also allows me to predict future user frustrations that may arise from implementing the new product.

    Persona Development: This practice allows me to compile my empathy map and shadowing findings. I then can test how a well-defined sample user might fit into the product.

  • After my user groups are well defined I construct a pyramid of user hierarchy. This creates a reference point for the rest of my project. Any tradeoffs that ned to be made are referenced to this map so I know which user group should have to experience the tradeoff. It also allows me to have a clear priority of my super user(s) when structuring the product.

  • I then begin creating components and the building blocks of the product. These building blocks are the various systems, pages, views, or stages that a user may reach during use. Each of these blocks contain sets of features that a user can interact with. I like to start with the navigation building blocks and expand from there.

  • I then reference my interaction map and and create full wireframes for standard cases and any speciality special case. These wireframes included more details on smaller interactions by a user and how it will handle fringe and special cases. Ensuring everything has been accounted for prior to mocking allows me to create more intuitive and user friendly designs that have more purposeful feature placement.

  • I then compile all the information collected previously to create a lo-fidelity pen to paper sketch of what the main navigation pages and subpages would look like and what kind of data would be structured on them. This practice allows for quick proofs of concept before investing more time on a detailed interactive mockup. I like to do this typically on Paper or on FigJam.

  • I then use my sketches as reference to build a high fidelity mockup(s) using Adobe XD or Figma. As I complete each page I wire the interactions to allow my team to fully navigate the mockup. This allows the team to get a feel for how the pages and elements should look and interact with each other.

Mind Map

I use mind mapping to start off the project to create stream of consciousness brainstorming of the projects depth. I dove deeper in this excercise than I intended but this helped me find the depths of circumstances that need to be accounted for. There are many concepts that are added to this map that I did not pursue any further than this.

Empathy Map

I created an empathy map to get a pulse on my users current experience. Documenting this allows me to think a little deeper about frustrations and actions that my user has. I then can better incorporate their interests in the core functions of the app.

Flow Chart

I created a flow chart as a precursor to a more detailed airframe for this project. This flow chart has the basic skeleton of which pages will exist and how navigation will function but does not have the depth of how each feature will interact with one another. Since the project contains a lot of interactions creating a flow chart before the wireframe allows a better more thorough map of the products bones before building up.

Low Fidelity Mockup

After establishing a general structure in the wireframe I like to make a low fidelity mockup to start creating the big components and some of their placement. I like to do this in two stages, the first bing the building of the mockup and the second being the annotations of the work. I often will repeat these stages until I create enough structure to start adding details. In this app I started by creating the main pages of the app and the general navigation concept. From there I began to work to fill in details to ensure the actions from the wireframe are reflective in the mockup and functional.

Rapid Development

From there I take my low fidelity mockup and begin to rapidly develop the looks of the page. As this development occurs the colors and fonts (if not preset by the master style guide) change and adjust until a look or feel for the product is set. Then the styling and the components are share across all pages of the app to create a high fidelity mockup for production and build. I typically take on this process by creating many versions and revisions until I have a structure that feels right or some that I’m ready to put out for polling or a vote. Below is some insight into that development. In this example the final version has not come into its final form yet, but you can see the process in getting there.

Previous
Previous

Trailmix

Next
Next

Logistics