Recruiting

I recruited participants mainly through Social Media.

I started out by joining as many Facebook groups for crafters as I could find! Some of these groups I already belonged to from my personal craft show days. I asked permission from the group administrator when possible, and then posted my screener survey in these groups with a description of my project and what I needed help with. I went to a fine arts college, so I also posted the survey in my alma mater’s Alumni groups as well. I tried posting the screener in some Reddit groups dedicated to crafting… but these got denied due to the rules of the groups.

It was slow going at first, and I had to re-post the survey a few times, but then the responses started rolling in! I got over 50 responses to my screener survey. I then went through the responses, and organized them in a spreadsheet according to the following categories: Good Candidate, Less Desirable, Disqualified, Not Available, Does Not Want Interview.

Then, I started emailing invitations to interview! I sent each candidate an email with a link to Calendly where they could sign up for a time slot. I ended up sending out 23 interview invitations, and was able to schedule 5 interviews with candidates that met my requirements. 

SYNTHESIS

After interviewing potential users, I collected the most important, interesting points from each conversation, and created an affinity map. I began by writing down the most interesting and important points from each interviewee. Then, I rearranged each note, grouping the ideas by category, in order to gain insight into what was most important to the average user.

Insights

DEFINING THE USERS

Personas

It was important for the design process to keep the users in mind during the duration of the project, so I created personas for my potential users. In order to make them as realistic as possible, I created a spreadsheet to keep track of the similarities in demographics among my interview participants:

The majority of my interviewees worked in education, and all of them held college degrees, were female, and were between the ages of 25-35. Almost all of them even had a “K” sound in their name!

Empathy Map

I created an empathy map for The Crafter persona to help in my understanding of the user’s feelings, goals and actions:

Crafting A Solution

IDEATION

HOW MIGHT WE . . . ?

Now that I had a good understanding of the problem space and who my users would be, I was able to take their needs into consideration and frame them as questions that would help kick off my brainstorming. 

• How might we improve communication between organizers and crafters?

• How might we save time for both crafters and organizers?

  • How might we reduce the number of tools they need to use to organize information?

  • How might we streamline show information and application processes, so that it’s easily accessible and in one place?

• How might we help crafters to find the best places to show their products?

  • How might we filter show info for easier searching?

  • How might we allow crafters to track shows they plan to attend?

  • How might we allow crafters to see what additional perks a show might have?

• How might we help crafters have more success with sales?

  • How might we improve upon show promotion/marketing?

USER STORIES & MVP

Using these problem statements, I began to brainstorm many possible solutions for each. I like to begin collecting my ideas by writing down all of my ideas and making lists, and then organize all of the ideas into an outline, by category.

I tried to re-frame all of the most important user needs into the words of potential users by turning them into one-sentence “user stories”. I created a variety of user stories based upon the needs of the users that I discovered during my interviews and brainstorming. I then categorized these stories into a spreadsheet by Theme, and arranged them by Priority. This allowed me to determine which features would be included in the MVP, and which features might have to wait until a future version of the product. 

The purpose of this activity was basically to narrow the scope of the project to focus on the features that would be included in the first release of the product.

Site Map & User Flows

With the initial scope of the project narrowed down, I began to think about the flow of the product, and created a site map showing all of the pages that I would need to create, as well as user flows showing how the user would progress through those pages to complete a given task.

SKETCHES

Sketches: Version 1

Finally, it was time to start turning all of these ideas into something tangible! I thought about each of the user flows, and the screens that would be needed to navigate through each flow, and began to sketch out ideas of how those screens would be laid out.

Sketches Version 2: The Dashboard Problem

The dashboard is where the user finds themself upon opening the app. The dashboard displays a list of the user’s upcoming shows front and center. It was important that the user has an at-a-glance list of the most important information about their upcoming shows without having to navigate anywhere. 

I went back-and-forth a lot on what style of navigation the dashboard should use. 

My first instinct was to use a bottom navigation that would include a “to-do list” with notifications, a “messages” tab, a “search” tab, a “favorites” tab, and a calendar where the user could view their upcoming shows. I decided to limit the scope of the app, assuming that that most users would use their own personal calendars and emails, and that users don’t need another app with it’s own message system in addition to the slew of other messaging apps they have in their lives. 

Once I eliminated those features, the tab would only need to feature the “search” icon, and the “favorites” icon. I then started to wonder if it was even worth it to have the bottom navigation if there wouldn’t be as many areas to navigate to. At that point, I switched the idea to an accordion style navigation:

GUERILLA USABILITY TESTING

Now that I had my first round of the screens all drawn out, I imported them into Marvel.com’s POP platform to create an Interactive Prototype of my paper sketches.

I asked a few people to go through these paper prototypes with me during some guerilla usability tests in order to get an idea of any usability issues that I might have overlooked, and to gain insight or suggestions about the way the design was progressing.

During testing, I focused on the 3 main user flows: The Dashboard, the Search capability, and the Application capability.

Findings & Ideas

• Search Flow

  • The “Search” function ultimately allows the user to search for a craft show using various features. The search screen gives the option to create a new search or advanced search, gives the user filters to search with, and also shows recent searches that were performed, so that a user can easily find new shows with the same search parameters. 

  • I would change the language to be more specific than just the word “Search.” Some users were not sure what they would be searching for. (This may have been because not all users were the target user, so they were unfamiliar with the craft show world).

  • I had originally had the search include various filters, however some users thought that a more basic search should be the default option, where they only need to search by location. The filters get in the way of this being a quick, easy task. A separate “Advanced Search” option is where they would go if they desire to use the filters.

  • Add a photo in the show details that you can swipe through to see more photos or photos other users have uploaded

  • List the entrance fee in the search results (i ended up adding a filters area to the search results, and this is one of the filters)

  • In the list of results, someone suggested having a place where it tells you if you’re a good match for that show (i ended up having “suggested shows” appear on the dashboard)

• Apply Flow

  • The “Apply” function brings the user step-by-step through various form fields in order to complete an application for entry into the show. They need to fill out their information, select options, upload images, and submit payment all through this simple flow. 

  • I could have the application auto-populate with information from the user’s profile, rather than making the user fill out every field; I had previously only considered this by having a ‘use profile’ option when uploading portfolio images, but it makes sense to incorporate it in the entire application.

WIREFRAMES

Finally, I re-created the sketches digitally in Sketch as Wireframes, incorporating these changes, and made sure to arrange some wireflows that matched my user flows!

BACK TO THE DRAWING BOARD

Managing Shows

I was still really struggling with how the user would manage the shows that they had applied to, favorite shows, and past shows. I was really in love with one of my original ideas, which was to have a “My Shows” screen that featured tabs where you could toggle between “Upcoming Shows”, “Applied Shows”, and “Past Shows”. However, I was unable to see how this could be incorporated into the app with the accordian-style dashboard. 

After thinking about the user flow, I had decided to scrap this idea. 

It came down to simplicity: the user would have to travel deeper into the app to access the tabbed page (right), but with the accordion-style navigation (above), all of the information would be easily accessible right from the home page, without having to go anywhere else. This seemed to be the best solution for streamlining the user journey at the time.

The Dashboard Problem: Revisited

I was still unsure about how easily users would be able to figure out where to go to manage their shows. I had been reading about different styles of navigation, and decided to do some more sketches to compare navigation styles.

Dashboard Solution

After the new sketches and some more brainstorming, I finally decided on what I think was the best solution. I decided to go back to a bottom navigation, but this time the tabs would include “My Shows”, “Search”, and “Profile”. 

The most important information about upcoming shows would still be front-and-center on the dashboard, so that a user could simply open the app and see what they have coming up in one quick glance. I would add a list of “suggested” shows that the user might want to consider applying to on the dashboard. This not only makes the user’s life easier and saves them the time that it would take for them to go through the search process, but also invites the user to perform an action within the app. All of these changes would be incorporated during the hi-fidelity mockup phase of the project.

Visual Design

STYLE GUIDE

Using the mood board as a guide, I then created a logo, chose fonts and colors, and created a Style Guide and Stylescapes capturing the essence of the brand.

Hi-Fidelity Mockups

The Dashboard Problem: Revisited...again.

Remember that little issue I was having with deciding which style of dashboard was best for this project? 

Well since I was designing screens, I thought that I would start by designing each of those navigation style options in the product’s shiny new style - just to gain a little more clarity and ensure that I made the right decision.

Creating each option as a hi-fidelity mockup was very helpful in visualizing the potential navigation options. However, I still felt that the bottom navigation was the best decision. It allows the user to switch between the most important features of the app (managing shows and searching for shows) quickly and easily, and it is the best option when it comes to the possibility of scaling up the app’s features in the future. 

If I went with the accordion style, once the user attended numerous shows, the expanded menu for “Past Shows” would end up scrolling down for far too long. Separating the “My Shows” screen allows for each type of show to have its own area to grow.

HI-FIDELITY MOCKUPS - USER FLOWS

With the brand identity in place and a good direction of the visual design for the screens in place, I got busy building out each screen for the main red-route user flows using Figma.

PROTOTYPING & TESTING

PROTOTYPING

After each screen was built in Figma, I switched to prototype mode. I went through each screen and made connections linking each hotspot to its destination page.

USABILITY TESTING

So far, my app was lookin’ good! 💁🏻‍♀️

It was time to do some user testing in order to discover any usability problems in the flow of the app, and get a better understanding of a potential user’s overall impression of the product and visual design.

Recruiting

I set out to recruit testers who have experience applying for and attending craft shows. I started my recruitment by reaching out to those who I had interviewed during my initial interviews with potential users. I reached out to those who I had already interviewed, as well as those who I wasn’t able to interview the first time, but who met the qualification and had indicated that they were interested.

Testing: Round 1

I ended up completing my user testing with six users. Five of these tests were moderated and done via Skype, and one was unmoderated and completed through TryMyUI.com. 

I asked each of the testers to complete the following tasks:

• Look for a craft show that you might be interested in applying for

  • I chose to say “look for” because the search button on the home screen of the app says “find shows”, and I did not want to use any language that would give the user clues

• Apply to a craft show

• Check the status of an application for a show that you have previously applied to

• Finish an application that you started, but did not finish applying to yet

• Look at the shows that you have previously favorited so that you can decide which ones to apply to

Findings

I went through my notes, and created a spreadsheet listing each usability issue that came to my attention during my user testing. I ranked the severity of these issues on a scale with “Critical” needing the most attention, and “Normal” needing the least attention. Here are some of the most pressing issues that I discovered:

Issue No.1: Favorites

The biggest issue that I discovered with the product was regarding the ability to favorite items. Currently, when you search for shows you get a list of search results that meet your criteria. There are heart-shaped icons listed on this page affiliated with each show, as well as on the show detail page. The idea is that you can “favorite” some shows, and then go back and look at your favorites.

Unfortunately, I discovered that I had completely overlooked creating a screen where someone could go back and look at the shows that they had favorited! This is a very important feature, and needed to be incorporated. I needed to find a way to add this screen into the app, and thought that perhaps it would be able to go under the “Profile” section of the app, or under the “Search” section.

Issue No.2: Radio Buttons in the Application

In the Application portion of the app, there is a screen called “Requirements” where the user needs to select options that are available for the show. One section is options for the “Booth Location” they are renting. The options include different booth sizes and locations, and these options are all different prices. The issue is that in reality, a user would only be able to have one of these options. Right now, there are check boxes next to the options, and users have the ability to select more than one option. The “Booth Options” section should contain Radio Buttons instead, so that only one option can be selected. I made a plan to implement this change.

Issue No.3: Language

There seems to be some confusing language used throughout the app. In a few different places, users thought that a phrase meant something other than what it was intended to mean. I need to go through and make sure all language is clear.

Iteration - Version 2

I then put these plans into action, by going back to my prototype and implementing changes. 

Here are some of the changes I made:

Testing: Round 2

I completed a second usability test on the second iteration of the prototype. This time, five tests were done, all remotely as moderated usability tests.

Findings

Issue #1: Favorites

There are a few screens with the ability to filter search results. I discovered that it would be helpful to include the price in the list of search results. In addition, if you were to search by a different filter, the same field should reflect what the chosen filter is. In order to show what I mean, I would need to build out a second filter user flow in my prototype. This would show that when you are filtering by price, the price is shown on the right side of the search results, and then when you filter by distance, that field changes to the distance in miles. The field should reflect what the chosen filter is.

In my first round of testing, I had discovered that I hadn’t created a screen where users could go back and look at the craft shows that they favorited. I had made revisions to the design, and added this feature under the “Search” screen. However, it seems that having the “Favorites” show up under the search page is not intuitive for a user to find. 

It would be better to include Favorite Shows as its own tab within the “My Shows” page. There were already three tabs in that area, so I had originally thought that there would not be room for it in this location, and had decided to put it in the search area.

After re-thinking the order of things, I decided that in order to make room for the “Favorite Shows” tab, the best course of action would be to combine the “Upcoming” and “Applied” show tabs, and then give “Favorites” its own tab.

Issue #2: Filters

There are a few screens with the ability to filter search results. I discovered that it would be helpful to include the price in the list of search results. In addition, if you were to search by a different filter, the same field should reflect what the chosen filter is. In order to show what I mean, I would need to build out a second filter user flow in my prototype. This would show that when you are filtering by price, the price is shown on the right side of the search results, and then when you filter by distance, that field changes to the distance in miles. The field should reflect what the chosen filter is.

Issue #3 - Font Size

On the show detail page, the font size is too small. The “Show Detail” page is where a user lands after searching for a show, and clicking on one. Here, they see pictures of the show, the deadline to apply, and all of the information and requirements for that show. The font size seems to be too small for people to comfortably read so much information. I needed to go through the app and address the font size, and also make sure that the font size is okay in all other screens.

Issue #4 - Clarity on Show Detail Page

On the show detail page, at the top center of the page, it states the show’s deadline to apply. The idea was originally that this was very important to the user, as they need to make sure they get applications in on time. Putting it at the top center and color-coding it would create a sense of urgency. However, a user might think that something of this color and placement is a call-to-action button. It would be a good idea to make this appear less like a CTA, and increase the visibility of the actual button on this page to minimize confusion.

Iteration - Version 3

Once again, I went back to my prototype and implemented changes. 

Some of those changes are pictured below:

Conclusion

WRAP-UP

Throughout both my personal experience and research during this project, it is apparent that the craft show industry has fallen behind when it comes to current technology expectations. All of the crafters that I interviewed were excited about the prospect of this type of product, and I am optimistic that if this product comes to fruition, it will be helpful in solving this problem.

What I’ve Learned

From initial sketches, through to the completed hi-fidelity mockups, this project really helped me to think more about what the user needs, rather than creating something the way that I want to based solely on preference. I was faced with making decisions where my preference was not necessarily the best choice, and really embraced coming to that realization and trying to come up with alternate solutions. 

I was also surprised by how much I enjoyed the research and ideation parts of the UX design process, as those were what I was more nervous about in the beginning of this project. I had expected that I would like the visual design of course, but I really ended up enjoying brainstorming and coming up with ideas. 

In addition, I come from a graphic design background, and changing my thinking in this way has definitely made its way into my graphic design work more than it was previously. 

Check out the final Interactive Prototype here!