Joybloc [UX Design Case Study Ext.] : Designing a Creative Challenge Mobile App

Note: This post is the original case study written for the portfolio, and acts as a more in-depth analysis of my process. The current version of the case study is shortened for lighter reading.


Introduction

Hackathons, game jams, design sprints, and the like are great ways to get your hands dirty in a way that's quick and isn't a huge hit on resources. However, a few common issues I've run into when starting a project is finding a nugget of a great idea to build on.

Creator's block is a common plague within creative industries, and that's okay! It happens when we least expect it and can have us feeling pretty crummy, especially when we feel like we're unable to dislodge that block. Sometimes it's from overwork, health concerns, or maybe we don't have anything to start with.

I've wanted to overhaul my constraint generator prototype for a couple years now; since then I've learned a great deal about how others work, and how I conduct my own processes. I sought to create something that not only helps a creator find and manage an idea, but how to take care of themselves and those around them as well.

So with that in mind, how do I design an app that not only lets creative users practice their skills, but also provides an enjoyable collaborative experience?

joybloc_splash1.png
 

Project Overview

  • Objective: Finish and launch on the Android Play Store, Apple App Store, and online.
  • ConceptJoybloc is a creative challenge & collaboration app that enables beginners and veterans alike to test their creative ability.
  • Project Duration: June 2018 - July 2018 [UX Design, Preliminary Assessment]
  • Approach (Chronological Order): TBD
  • Role(s): UX Designer, Software Developer [Solo Dev, All Roles]
  • CollaboratorsPhilip N. [Survey Participant], Jasmin H.F. [Survey Participant], Karen D. [Survey Participant], Michy S. [Survey Participant]
  • Tools Used: Axure, Adobe XD, Adobe InDesign, Airtable, Google Suite, Android Studio, TBD: [Electron, Node.js] or [Unity, MS Visual Studio]
  • Links: Currently undergoing development.

I've been wanting to overhaul Conception (the creative brainstorming prototype that Joybloc is based on) for over two years now, but there's many other projects and activities I'd love to do-- things like making a chat app, a piece of downloadable software, or even a first-party website.

It's all really ambitious, but most of that drive comes from a general curiosity for how software runs on my tech, working in tandem with my wish to bring creatives together in a non-toxic and accessible way. By working in UX, I also get a front row seat in how my software is perceived, allowing me to understand where my projects might need to be improved.

Joybloc is meant to be my creative outlet for bringing all of that together, and more. Like my previous projects, designing and developing it would require more breadth and depth of skill that I currently possess. But personally, I like working on stuff where I can chew on it for some time-- where's the fun in a project if it doesn't sound impossible?

 

User Research & Assessment

To compose a market strategy, I first need to understand if the target audience would even need an app like Joybloc. How does creativity fit into their life? Do they struggle with motivation and/or communication? How would creators practice a skill they didn't know is pertinent to their field? How would Joybloc ease common anxieties?

By gathering and assessing data from creators, I'll understand common obstacles to creative expression in order to compose a comfortable UX design and a low-risk market strategy. The results from the User Interviews were as follows:

  • Physical and mental exhaustion are primary causes for a lack of creative effort.
  • Creators can find it difficult to block out time into their day for creative skill-building.
  • It can be difficult to make anything without a defined structure or challenge.
  • Outside of Facebook and Instagram, there is no streamlined method of communication between creative individuals.
  • There is a strong correlation between social avoidance and a lack of motivation. People who receive support in social circles may be more productive in general-- regardless of whether the person has social anxiety or not.
  • Creators place self-expression above all else, regardless of form or function.

User Interviews

To best assess the needs of the creative community, I set up a three-part survey assessment to understand how Joybloc might fit into their creative process. The target user group included creators who would like to challenge themselves more often, find others to collab with, and would like to attend/organize more creative events -- regardless of age or discipline. I first sent the survey out to creatives who share their art on a regular basis and challenge themselves often, and later on I opened up the survey to anyone who wanted to be expressive more often through creative work. I asked that the survey requires a minimum of 5 participants, with an optimal amount of 10 participants.

By subtly masking how the prompts are phrased and ordered, the survey is designed so that previous questions/answers are not as prone to conflicting with future questions/answers.

The Creative Output section is framed in a way that allows the participant to reflect on their daily life, schedule, toolkit, and goals (while not revealing any app features). Providing statements on these details give the person a fresh perspective on their day, how much time we may limit the app's challenges to, who our competitors and partners might be, and why the creator might feel inadequate in their current ability.

The Collaboration section is used to see if communication and social gatherings are influential to a person's creative willpower, how the creator views the important of communication in their personal growth, and their social preferences. Just like the first section, I'm trying to understand the perspective of creators on two opposite sides of two different spectrums: creators who make content regularly, creators who seldom make content, creators who prefer to work with others, and creators who'd rather work alone.

The Software App section is where users are provided insight into the app's functionality. By asking participants to highlight features they'd see themselves using, I'm able to understand what creators want most, rather than what's best in terms of personal growth. Despite what the data provides, I'm not just looking for what features to implement first. I'm also searching to see if a universal pattern emerges between creators in order to understand what drives them, and what motivates them to keep creating.

In addition, many people (myself included) have a difficult time accurately predicting what they'll do in the future. Because of this, I can't rely heavily on what a participant says they'll utilize, but their responses still provide an idea of the problems they're facing and what they'd want out of the project.

The following results are based on a total of five survey participants. (Percentages often do not add up to 100% since many prompts allow for multiple selections.)

Creative Output:

  • Causes for Lack of Creative Output
    • 80% of applicants said they're too exhausted after work to be creative.
    • 60% said there isn't enough time in their schedule to be creative.
    • 40% said they'd rather do something more engaging with their time.
    • 20% said they've become more disinterested in their creative field.
  • Output Frequency
    • 40% said they currently make stuff twice a week.
    • 40% said they make stuff three times a week.
    • 20% said they make stuff four times a week.
  • Output Preference
    • 40% said they'd prefer to make stuff seven times a week.
    • 20% said they'd prefer six times a week.
    • 20% said they'd prefer five times a week.
    • 20% said they'd prefer three times a week.
  • Creative Duration
    • 60% said they spend an average of 3 hours per project (illustration is assumed).
    • 20% said they spend about one week per project (3D modeling is assumed).
    • 20% said they spend about two weeks per project (software dev is assumed).
    • 20% said they spend about three months per project (3D environmental art is assumed).
  • Resource/Technique Use
    • 60% said they use no specific source to practice their creative ability.
    • 40% said they use Udemy and Itch.io.
    • 20% said they use Pluralsight, SoloLearn, Lynda.com, One Project a Week, One Project a Month, and Pomodoro.
  • Technological and Lifestyle Obstacles
    • 60% said they experience software glitches often.
    • 60% said they don't have the time or energy to make stuff in their free time.
    • 40% said it took some time to save up the funds needed to purchase the necessary tools.

Collaboration:

  • Event Attendance
    • 60% said they attend game jams to practice their creative ability.
    • 20% said they attend casual art meet-ups.
    • 20% they do not attend any events.
  • Communication
    • 100% said they used Facebook and Instagram to communicate.
    • 80% said they use Twitter.
    • 40% said they use Discord and Slack.
    • 20% said they use Google Hangouts, Skype, Steam, First-Party Game Clients (ex. Blizzard client, LoL client), LINE, phone call/text, KakaoTalk, Tumblr.
  • Networking
    • 40% said they find people to meet up with via Twitter, Discord, on-site networking, or they avoid meet-ups altogether.
    • 20% said they use Facebook for meet-ups.
  • Social Preference
    • 40% prefer to make stuff alongside friends and don't mind if an acquaintance is invited.
    • 20% said they don't mind working with anybody (assuming casual-professional courtesies).
    • 20% said they prefer to make stuff alongside friends, but just close friends.
    • 20% prefer to work alone.
  • Social Affinity
    • 80% said they like to make things alongside others, but they like their personal space too.
    • 20% said they like to make things alongside others most of the time.
  • Collaborative Status
    • 40% said they like being creative with their current group.
    • 40% said they have a difficult time finding someone to collaborate with.
    • 40% said they prefer to not collaborate.
    • 20% said their current group could use more people.

Software Application:

  • App Interest
    • 60% said they'd certainly use the app.
    • 40% said they might use the app.
  • Cause for App Disinterest
    • 50% of those who said "Maybe" (to the previous prompt) have trouble keeping track of things, so regular use isn't guaranteed despite its usefulness.
    • 50% said they don't usually use or stick to a single app, and most of their energy goes toward work and drawing.
  • App Integration
    • 60% said they'd use the app once a day.
    • 20% said they'd use the app every other day.
    • 20% said they'd use the app about twice a week.
  • App Features
    • 100% said they'd use the Role Selection and Profile Customization.
    • 80% said they'd use the Challenge Generator, Event Bulletin, Collab Chat, Progress Tracker, and Project Timer.
  • App Suggestions - Applicants have suggested Custom Challenges so users can come up with their own topics and constraints, an Inspiration Board to save/share content that inspires current/past projects, Anonymous Feedback Boards to give feedback to other creators, and a Save Constraint Generation option to save/share ridiculous challenges and submission that might have generated.

User Personas

By using the insights discovered from the surveys, we can compose primary and secondary personas that would represent individuals using the app. The first persona shown below acts as the Primary Persona who would best personify the app's target user, while the next two are the Secondary Personas who personify the app's secondary features.

 

Task Analysis

The goal for this stage is to gain a better understanding of how our community relates to Joybloc over time. The journey maps will need to start with how each persona will discover the app, become compelled to use the app, register for the app, learn how to use the app, and finally how users become passionate regulars.

I started with some journey map prep to get a sense of what the user wants to do with the app, how they'd be using it, and how'd they feel during each interaction with the app. This would also include an empathy map sketch, an affinity diagram in large-team setting, using SCAMPER to detect feature bloat, and (once a working prototype is established) a red route analysis to observe which tasks are being used most often by users.

User Journey Maps

To refresh on the interview results, creators are often too exhausted to express themselves creatively as much as they'd like to be. Fitting this creativity into their busy schedules isn't always viable, especially since many artists (the app's expected core audience) have a tendency to be overworked. Without a specified structure or constraint, it can be difficult to bypass creator's block. Facebook and Instagram are the most popular methods of communication, but neither app is tailored to casual professionalism in an expressive environment. Individuals who receive encouraging support within social circles are more likely to be productive and engaged in their work, and creators place self-expression above all else.

I started with some prep notes to consolidate the personas down to actionable statements, and determined the touchpoints and channels that are likely to be used for each persona. To ensure that the app also has interactions that the user might find enjoyable, a list of positive interaction systems were also noted.

Due to time constraints, I focused on Persona A and started working on Empathy Mapping and the final Journey Map for that user type alone. There was also a growing concern regarding feature bloat, and choosing to create and Empathy Map and Journey Map for the two secondary personas would require an additional commitment to the features tailored to those users. I chose to focus on the primary persona's needs and emotions, while the secondary features could either be revisited at a later time or outright removed.

Using the information noted in the sketches above, a rough Journey Map was drawn out in order to illustrate the user's thought process as they use the app over the course of a few weeks. The finalized Journey Map is used as a visual aid by outlining how we want the user to behave and respond throughout each stage of the app's lifetime. The Map can be used not only within the design/development team, but can also be presented to clients and any other team members working on the project.

ux_sketch_journeymap.jpg
ux_portfolio_journey_map.png

Feature Bloat: UX Design SCAMPER Verdict

Using the SCAMPER Method, Joybloc underwent a final run of heavy scrutiny before attempting any sort of prototyping. In order to design a tight and cohesive app, any features that I had second thoughts on were either cut, delayed, or modified to focus on creating an app meant to challenge creators, similar to that of the original prototype. Collaboration, while still a strong focus, was chosen to be prioritized at a later date.

- IDEATION -

Substitute:

  • Should I replace the original black/white retro aesthetic with vivid playful colors?
  • Do I use Electron/Node.js for streamlined third-party functionality and scalable growth, or Unity/C# for graphical fidelity, operating power & software familiarity?
  • Should I design and develop Joybloc as a mobile app first, and a software/web app later?
  • What if the social media feature is instead distilled down to simple project updates and recent events?

Combine:

  • Would it be viable to merge challenges and events into a single process?
  • Do I focus on the original concept of challenge and trial, or should I keep working to expand the app into facilitating collaboration?

Adapt:

  • Should I incorporate break times and healthy habits (like stretching and walking around for a bit) into the creation of a project, or during a challenge?
  • Would implementing an inspiration board like Pinterest come with legal consequences regarding Creative Commons?
  • If a user-network-based functionality is implemented, what would need to be done in order to prevent feature bloat?

Modify:

  • Should I focus less on articulating the meaning of a constraint/challenge like in the prototype, and instead let the user research the constraints on their own?
  • Should features like the Timer be modified to be used for any project-- work or personal?
  • Should I remove the "Tool Guide" aspect and instead loosely group similar/related constraints together based on common knowledge & terminology?

Put to Another Use:

  • Would the app be accessible to all ages?
  • How would a user with limited eyesight or physical/mental ability use the app? Could they use it at all?
  • What if it were used on a smart watch?
  • Would implementing an online web version be more accessible to those without a smartphone?
  • Would instant online access be an impassable barrier to those outside the country like China or Cuba?

Eliminate:

  • Would a social media feature really be beneficial to a challenge/collab app?
  • Should I postpone the Events feature for a later date?
  • Is the use of 3D modeling absolutely necessary for the app, or is 2D animation suitable?

Rearrange:

  • What if challenge constraints were presented in fewer numbers (3 constraints instead of 7)?
  • Would it be beneficial to combine the mechanics, dynamics, and aesthetic challenges into a single field of expertise, or to overhaul them altogether?

 

- VERDICT -

Core Features:

  • Joybloc's challenges will provide 3-5 constraints instead of Conception's 7. Role specialization also plays a role in what constraints are generated-- instead of just focusing on Game Design and UX Design, there will also be challenges based on the fundamentals of graphic design, programming, sound design, etc.
  • Roles will be divided into three distinct groups: Design, Craft, and Make.
    • Designing includes video production, sound design, graphic design, game design, and UX design.
    • Crafting includes jewelry, physical art installations, albums, collages, knitting, crocheting, pottery, and writing.
    • Making includes robotics, 3D printing, programming, woodworking, metalworking, and glassworking.
  • If the Project Timer is running, the user is forced to take a break every 30-60 minutes (the break can be postponed for 5 minutes and used ad infinitum like a snooze alarm). The break lasts for ten minutes and provides the user with prompts for stretching and health advice tidbits.
  • The Timer can also be used for any project at anytime, whether its a personal project or for work. It can be adjusted for multi-day project schedules and deadlines can be set when needed.
  • To stay up to date on your friends' and followers' projects, feedback and responses should be streamlined and positive while also constructive. Instead of a Facebook-Twitter style feed, Joybloc's feed could be a hybrid akin to that of Discord's "Games Being Played" feed and Rocket League's controller-based conversation phrases, with the option to manually type in feedback.

Aesthetics:

  • Design the app using a playful and colorful palette to mimic high activity and excitement.
  • The visuals and sound effects should be expressive while also allowing for plenty of customization.
  • While interactive 3D art would be a great way to stand out from the competition, 2D would be easier on personal resources and the user's battery life & memory usage. As much as I'd like to, Joybloc shouldn't be developed using game dev software.

Accessibility:

  • Develop the app with Electron/Node.js for decreased loading time, an easier transition towards web and software development, voice recognition and readability, blind accessibility, and minimal memory/battery usage.

Process:

  • Focus on mobile development first, web second, and software third.
  • Roles, Challenges, and Constraints will be implemented first. Projects, Events, and other collab-focused features can be implemented later, especially since a brand new social app is moot without users already in place. Focus on an offline experience for the initial release.

Miscellaneous:

  • Once collaboration-based features are a major focus again, gradual steps need to be taken. Start with an Event Bulletin, Friends List & Chat System and troubleshoot as needed. Look into more robust social interaction systems afterwards.
  • Unlike Conception, Joybloc should allow more freedom of thought by not interpreting the constraint for the player. The Tool Guide won't be implemented and terms won't be strictly defined, but core specialization concepts will still be provided as challenges for various fields of expertise.
 

Prototyping

Low-Fidelity Paper Prototype

I started with sketching out a task flow diagram that provided an overview of the app's primary functions. Afterwards, I worked on a paper prototype focused on the homepage, role selection during the preference setup stage, and the projects section of the app.

To work with the challenges of solo design and development,, these paper prototypes are less meant to be tested with users. They're intended to actualize what information needs to be provided on a given screen, how that information is presented, and how the user might interact with the app. Digital tools like Adobe XD allow more flexibility in designing the interactions and UI of the app by quickly re-arranging elements as needed, and gain results from user testing immediately.

Quick note: In the previous section I mentioned that I wouldn't worry about collaborative features just yet, and this is still true. Until the app's development and release, I'll be keeping in mind how the collaborative aspect fits in with the rest of the app, but the features won't be extensively developed until post-release.

joybloc_sketch_taskflow.jpg
joyblock_sketch_prototype1.jpg
joybloc_sketch_prototype2.jpg

Low-Fidelity Adobe XD Prototype

**Progress underway!

joybloc_ss_prototype1.png
 

Takeaways

The project isn't done yet-- but it's pretty dope so far!