Chronicles of a Design Project

Part 5: Iterating and Finalizing MVP Designs

In my last post, I showed you how I used paper prototypes to quickly iterate the design and the layout of the major features of Color Stash, a platform to help artists keep track of their colors. That exercise allowed me to quickly iterate on the overall direction of the platform, without getting bogged down by details.

In this post, I will explain how I moved from paper to digital, and finished the first MVP prototypes in six weeks. I opted for a process that allowed for exploration, while at the same time it reduced the need for fiddly and hard-to-track adjustments.

Here is a look at some of the interesting challenges and what I learned along the way.

Managing time and deliverables

Color Stash is a decent size project. It involves multiple scenarios, and many detailed flows. So, it was crucial that I find a way to manage and reliably predict my workload. Prior to this project, I had relied on a number of tools:

  • Trello to track my tasks in every sprint.
  • Gantt charts to view project milestones and assess the progress toward them
  • Spreadsheets to keep a detailed record of time I had spent per task.

All these tools have been valuable in helping me keep my work organized and meet the deadlines. Starting with this project, however, I decided that delivering on time is not enough. I also wanted to get better at estimating the workload for each task, so that my projections for what I can get done, without overextending myself, become more accurate.

I borrowed Fibonacci points from Scrum project management techniques. I found it very useful, because Fibonacci points forced me to think in terms of “time buckets” and how much of a “task” I can fit in a bucket. When I kept track of my work in actual minutes, it created too much visual clutter. It was hard to work through every extra minute to get a sense of how much time different types of tasks took. Instead, Fibonacci points gave me a simple and consistent system to wrap my head around. Here is a quick overview:

Basically, you are given a number of set tokens: 0.5, 1, 2, 3, 5, 8, 13, 21.

The way I used it, I set “5” as the bucket for how much I could get done in a day. That gave me 25 tokens per sprint (one week). At the start of a sprint, I would assign a token to every task based on my expectation of how long it would take.

You can see the aggregate points for every list

Now, here is the critical part, at the time of completing a task, I added another token that reflected the actual time and effort I put in. This way, I could do a retrospective on the discrepancies between my expected and actual Fibonacci points at the end of every sprint.

You can compare your aggregate estimated time, with aggregate actual time.

Gradually I became better at estimating, so that now it is much easier for me to predict the deliverables for every sprint. I should add that people use Fibonacci points in slightly different ways, and you should probably play around to see what works for you, if you choose to use them.

But regardless of how they are used, Fibonacci points give the notion of “time and effort” a very tangible quality.

Sprint Zero: Establishing a Process

Different teams approach sprint zero in different ways. My objective was to set the baseline for the processes that would guide me through design and prototyping.

Researching tools and techniques

I spent the first part of the sprint researching. That’s when I learned about Fibonacci points. I also delved deeper into design systems. I was trying to find tools and methods to help me balance speed with the creativity that a project at such an early stage needs.

Setting up the platform’s skeleton

The second part of the sprint was about trying out a process to see how the different tools and methods came together. That meant that I had to start building, and there were two options before me: either pick one scenario and work through it, or create “the skeleton” of the entire platform, that is, building its main views and critical interactions. I chose the latter, because it presented several advantages:

  1. A sense of scope: It gave me a chance to think through the potential detail involved in some of the flows and get a sense of how I should divide the work in the subsequent sprints.
  2. Surfacing commonalities: Instead of looking at scenarios in isolation, I got a holistic view of the app, which allowed me to decide where I could make reusable components.
  3. Bolstering client confidence: By the end of the sprint, I was able to provide my client a tangible deliverable that, without going in detail, simulated what the entire platform would be like in a couple of weeks. This way, I was able to rekindle her confidence in our partnership.

Here are a few of the scenarios that were developed for this sprint:

Artists need to be able to easily enter their colors into Color Stash
Artists want to group colors related to the same
 artwork, further group those that go together.

After Sprint Zero: Meeting The MVP Goals

In total, I did six sprints (0 to 5), each spanning a week, and created three prototypes. I followed an iterative process: I began every sprint, other than sprint zero, by sifting through the test results from the previous sprint, and I ended each one by testing my designs with an artist.

Breakdown of the design sprint for the first Color Stash MVP.

Before, I give you some of the interesting takeaways, let me go over the main scenarios that ColorStash supports:

Artists can enter their colors, whether manually or by scanning the barcode, into the system and build up an inventory. They can create projects, where they will store colors used in a particular artwork. Finally, Inside every project, they can group colors that go together.

Artists can quickly see what colors they have, and which
 ones they are about to run out of.
Artists can quickly scan in their markers and add them
 to their main inventory or a project.
Artists want to group colors related to the same
 artwork, further group those that go together.
Artists can add colors to their projects from their main inventory.

Here are some of the takeaways:

A. The desired level of affordance can greatly impact the design of interactions

In Color Stash, Color cards can be move into projects from the main inventory, or they can be moved into groups once they are inside a project.

Multiselect is a critical feature, and in coming up with the right design for it, I had to consider two different patterns: One that relies on touch ( as in Google photos), and another that provides explicit triggers for action ( as in Apple photos app). I picked the latter with more explicit call-to-actions. My thinking behind that was that ColorStash is a digital tool for artists whose medium of work is physical. So it is reasonable to assume that some of them may feel more comfortable with explicit hints when navigating a digital medium.

B. Great feedback, and microcopy are critical to fluid and intuitive interactions

Too many hints or too much feedback can break the flow, irritate the users, and worse case scenario, confuse them. I had to find a balanced way of presenting the extra information that supports every flow.

That became particularly challenging when designing guides for scanning. There were many technical aspects of scanning that still had to be figured out, and depending on the solutions, the guide’s content could be very different. So, I had to make sure that my design is as flexible as possible and at the same won’t take up unnecessary space.

C. Think about points of failure

Also, at this early stage, it is interesting to start thinking about potential points of failure, and strategize how to solicit feedback. For example, in Color Stash, if an artist manipulates the outcome of what’s just been scanned in, does that necessarily imply a failure in the accuracy of scanning? Should there the user be asked for their feedback each time they adjusting something after scanning them? I decided against soliciting feedback, because at this early stage, we have no actual usage data. I marked this interaction as one that needs to be monitored when there is more data.

D. Don’t underestimate the depth of information you can reveal on a tiny card

Color cards are one of the critical objects in Color Stash. They contain all the information attributed to a color. When defining the object model of the platform earlier in the design, a complicating factor was that Copic provides different types of markers, together with filler inks for every color. That can quickly amount to a lot of information per card.

At this stage, I had to find ways to surface the useful information without overwhelming the artists. An interesting challenge was how to distinguish between markers or fills that are running out, and when one or the other was not yet purchased for a given color. To show filler inks at 0 quantity, when the artist has never bought any, would be to overwhelm them with unnecessary information.

So, by the end, a quick look at a color card thumbnail can reveal a lot of information that’s relevant to an artist.

The rabbit hole of a thousand possibilities

Be warned against rabbit holes, tasks that suck you in and use up your time. Here is one that I had to grapple with:

I wanted to make it as painless as possible to help artists find color cards. But, as I started exploring different types of interactions for filtering cards, I noticed that I was spending too much time on trying different patterns.

You might be wondering, what helped get me out of that rabbit hole? It was the realization that all I really knew about the actual filtering needs of artists was that they will want to know what colors are about to run out. So, I started to focus my design explorations on ways to reveal just that information, until the MVP is launched, and we get data and feedback from the users.

Conclusion

The Color Stash Mobile MVP designs are now complete. Here are a few resources that I found very helpful throughout the six sprints it took to take Color Stash to where it is:

  • Design Systems by Alla Kholmatova: Kholmatova’s book is a practical guide with plenty of concrete examples and actionable tips about different types of design systems and how to approach building one.
  • Pablo Stanley’s tutorials: Pablo is a designer and a great educator. He has plenty of videos on Youtube. I particularly found his “Creating a button system with nested symbols” useful in helping me to make my designs more modular and reusable.

Next

I will be working on the desktop version of Color Stash soon. A lot of the styles and patterns are already defined. The challenge is now to translate them to the web.

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