Chronicles of a Design Project

Part 6: From Mobile to Web

Earlier this year, I started chronicling my design process for Color Stash, a platform that helps artists keep track of their colors. In this article, I will talk about how I took my designs for the mobile app and translated them to the web. But before I dive in, let me do a recap of what’s been done up to this point.

Color Stash: Mobile v.s Web

Recap

Color Stash was a client project I started about May. With the client’s agreement, I expanded the scope of the project to interview artists and research the future potential of the platform. I spoke to 5 different artists to better understand how they manage and keep track of their colors. The key learning outcome was discovering the kind of artists we should target. These are artists who are limited by their medium ( such as markers, spray paint, embroidery artists, etc ) in their ability to mix colors. So, they have to invest in purchasing every shade of the color they need.

Next, based on the research, I built use case scenarios, and specified the scope of the first MVP. Having done that, I tried to figure out the information architecture of the platform, and then did a number of exploratory designs. Finally, in a series of six sprints, I moved the design from low-fi concepts, to high-fi prototypes that met the design needs of the first MVP.

Web app

The web app is the second MVP for Color Stash. The design for it was done in four sprints.

Breakdown of the design sprint for first Color Stash MVP

In this article, I will focus on what I learned in the process of making the web app, and mention some of the challenges and big differences between web and mobile that I had to deal with.

Picking the right tool

So far in the project, I had created my designs in Sketch and used InVision to make clickable prototypes. It was a flow that worked for me, especially with all the extensions that helped speed up my work. Starting with the web app, however, I decided to switch to Figma, for two reasons:

  1. I wanted to test out Figma’s native tools for creating responsive web apps.
  2. My client was setting off for a two week long trip, so I wanted to try out Figma’s online collaboration and prototyping tools, and keep my client involved with the project in that time period.

For the most part, moving from Sketch to Figma was a smooth transition.

Sketch v.s Figma

Here are some of the more significant differences:

  1. In Figma you can stack artboards (called “frames”) . This means that for the same page that you are designing, you can place different sections on different artboards, which makes it easier to apply multiple grid systems, or pin your designs for responsiveness.
  2. Symbols ( called “components”) and style guides for fonts are more versatile in Figma, and you can directly apply overrides to them.

That said, for the most part the two were similar. Obviously, Figma does not have the rich collection of extensions that Sketch benefits from. But, I assume that will be coming at some point.

The fact that the entire project was online made the communication between my client and me easy. During our conversations, I could instantly implement some of the comments and changes, and they could always have access to my designs.

A consistent experience across media

In tackling the web, it was crucial to maintain the unity of the brand across different media. That meant that before I could start building, I had to go back to the mobile app and look at what was already done. While designing the mobile app for Color Stash, a lot was decided as to the look and feel of the platform, and its main functions. It was critical to draw on these decisions for the design of the web, in order to:

  1. Keep the visual style consistent
  2. Keep the system’s behavior consistent

Given how much was already defined for the different pieces of the web app, I opted for the atomic design process. The idea is that you make reusable design components by breaking your designs down into three (or more) stages of development and maturity:

  1. Atoms: Color Pallet; Fonts; Icons;
  2. Molecules: Buttons; Tabs ; Sliders
  3. Organisms: Cards; Bars; Tables; Pages.

Defining the right navigation for the web

When working on a mobile project for iOS, there are a lot of standard design patterns that as a designer I can rely on. Navigation is one of those: Tabs or Hamburger Menus are two of the more common patterns to reveal an app’s main navigation. On web there is a lot of room for free exploration, with which can come a lot of inconstancy and confusion.

Figuring out the best path

So,To figure out what would be the right way to reveal the navigation for the web, I started out by breaking down the navigation into three parts :

  1. Main Navigation for the major sections of the platform: MyColors, Projects, Stastics, Profile.
  2. Global actions like search
  3. Contextual navigation and actions.

I then iterated on different layouts and configurations of these parts. In the final layout, I combined parts two and three in the top menu bar, and revealed the main navigation as a sidebar that expands to reveal more information.

Color Stash web navigation

Incorporating Hover State

An interesting difference between mobile and web is the hover state. Since, I had already designed the platform without any hover state for mobile, the question was how I could improve the experience now that I had this extra tool. Would it make sense to render certain interactions on the web with the help of hover state?

Hover was critical in designing the interaction for selecting color cards:

In Color Stash, artists can select colors from their main inventory to add them to a project, where they keep all the colors related to the same artwork.In the mobile version this flow is supported by a button as an explicit trigger and alternatively deep touch. Translating that flow to the web, I used hover state to reveal the selection option.

Prototyping Hover State

Hover state can be particularly tedious to prototype, especially when it affects multiple consecutive elements, as was the case with the color cards. That is because, during the test, the user may hover over any of the cards on their way to the actual card they need to move. In that case, every card should display the proper hover state in order for the experience to be realistic.

As of now, I haven’t been able to find any tools that, aside from the basic hover state functionality, actually address the issues I brought up and make prototyping for hover state easier. So, for now, I deal with hover state case by case, always considering what I am trying to learn from my prototypes, and whether or not I must thoroughly develop the hover state in the prototype.

Conclusion

As an artist myself, I really enjoyed working on Color Stash and getting a better understanding of how fellow artists approach use colors. I also found it very useful to chronicle the process, as I was doing it. Even though I did not have the benefit of collaborating in a team for this project, the fact that I had to write about it gave me a great chance to do a retrospective of how it’s been moving along.

Index

Part 1: What’s the big problem?
Part 2: Exploratory research
Part 3: Design phase kick off
Part 4: Exploration of the design through low-fi
Part 5: Iterating and finalizing MVP designs
Part 6: From mobile to web