Traxis: Your studio assistant

It can start with a problem bigger than you can solve.

Having spent time at art school, I have empathy for artists. Especially for those who try to make it a career. I want them all to make it. And before they make it, I want the cruel, commercial world to not crush them.

Out of 2 million arts graduates nationally, only 10 percent, or 200,000 people, make their primary earnings as working artists. — (BFAMFAPhD)

From what I’ve seen and heard, the first few years out of school is the make-or-break period. My idea was to help artists get things done, to see more success in their first career steps.

In short, I wanted to make a mobile app that could meet the unique needs of artists. Artists who were…

1. interested in a sustainable career as artists,
2. 1–5 years out of art school (of course),
3. and career-focused rather than sales-focused.

Sales-focused artists have clearer needs. They have tools like Etsy, Hubspot, Redbubble, Zoho, Facebook Ads, to help them.

I wanted to help artists who were interested in creating sustainable but experimental careers. The ones that aimed to exhibit, or create public art. Because their needs are more elusive, there would be new opportunities to meet them.

My research goal was to discover problems artists face in their careers. Within the first 5 years of leaving art school.

Your users are real people and you can ask them about their problems

I drafted my questions. For example, “what do artists use to keep track of their progress and plan their projects?”

My first questions were valid. But they were too solution-focused rather than user-focused. They were heavy with assumptions.

I revised my questions.

Cutting my assumptions opened my research to rich discovery. It stopped me from biasing interviewees. It helped me discover real motivations, real problems, and real opportunities.

I had a few ways of getting the qualitative data/answers I was looking for, but I opted for interviews. My budget was out of pocket. And you should always reward participants according to their level of effort. A $15 Amazon gift card is much more suited to a 30-minute interview than a 3-day study (see: Diary Study, Field Study).

I listened and learned. It took patience. It took a lot of “why is that?” or “please, explain”. Most of all, it took simple questions and diligent notes.

A single note doesn’t mean much, but a matching set means a lot

Grouping your notes into themes helps you find dominant sentiments.

I first analyzed my notes to find common themes by sorting them into themes. Joys, pains, process, and goals.

By noting how common comments were, within a theme, I could add credibility. An example in the pain category is four out of five interviewees said they were bad at managing their time. That’s compelling data.

Talking one-on-one with artists also taught me their vocabulary. I was able to use their language in the product later, and to even help me write a value proposition.

The value proposition changes once you talk to real people

My value proposition began as…

A productivity tool for artists. It gamifies your career, encourages production, and keeps track of deadlines, projects, and opportunities.

Only one part of that held up after the interviews.

I validated that artists needed to keep track of deadlines to meet their goals. But my findings told me artists especially needed confidence, motivation, focus, and inspiration. The biggest opportunity I saw was that inspiration comes from research. Every user agreed. They were inspired through collecting images, videos, articles, and/or their own thoughts.

And getting quality studio time was their strategy, no matter what their goal was. Good time management, to them, meant making time to make, read, and research in the studio.

My new value proposition, made from the user’s own language, became…

A tool for better studio time. Stay on top of what’s next, capture your ideas, and get inspired.

The proposition was directed at Jan. She was my persona. Depicted as one person, she’s a synthesis of the most dominant qualities I could back up with observation, analysis, and data.

Her qualitative data came from survey and interview questions I collected. Her quantitative data came from public reports, national surveys, and census data.

I’ll concede, there are some educated guesses in there. Jan’s salary? I’m not clear on that. The number of times she’s shown her art? Not sure. They’re details to help depict her: she doesn’t have a wealth of money or experience.

But her motivations, pains, goals, and technical capabilities are based on real data. It’s mission-critical to understand those qualities. You can’t design the right product without understanding who it’s for.

Cut features, but keep the core experience

I next listed my ideas as user stories— as a _____, I want to ______, so I can _____. Then I found a shortcut to get to an MVP.

Cutting the social components wouldn’t compromise the experience. Social features would benefit the product later on for retention and share-ability. But for now, a non-social product would be an excellent proof of concept. And in the market of Jan’s favorite apps, many are very anti-social. See: Cargo, Netflix, Spotify, iOS Notes, and Are.na. Their social features are secondary or non-existent to their value.

Re: features. Three out of the five interviewees mentioned a calendar could have huge benefit to them. The MVP’s basis would be a calendar.

Other features looked like a studio log for Jan’s notes, boards for her research, and tasks for to-dos. If the calendar showed her deadlines and notes, it could be a powerful tool.

Build it quickly

Each user I interviewed was invested in the iOS ecosystem, so I went forward sketching the structure and content for a mobile app.

Normally at this point, I would sit down with a few users to make sure their expectations matched what they were seeing. I you check that a user’s mental model fits the system model, it can prevent headaches down the road. However, I wanted to get a prototype in people’s hands as soon as possible.

Get design critique before user feedback

For my prototype’s first iteration, I made designs that covered the entire app. All the details. It meant designing the screens for Jan to edit, delete and manipulate her content, not just add it.

I got feedback immediately from other designers. Thankfully they let me know the product features needed more context.

In the second iteration, I gave context throughout the experience. Onboarding details. Key visuals. Tips that progressively disclose features. Introductory feature-benefit images.

The app was test-ready.

Watch and listen

Usability testing is a tried and true process to identify points of friction in a user’s experience. It involves getting the prototype into users’ hands, giving users tasks, and evaluating the design based on ease and difficulty. A critical step to designing something intuitive, usable, and delightful.

It’s an unfortunate but diagnosable truth that you never get a design right the first time.

In-person sessions are great, but unmoderated remote tests are more efficient. 5–10 sessions is industry standard. With the first five sessions, you’ll discover plenty. Afterward, you’ll start getting diminishing returns. If you have 20 discoveries in the first five tests, you’ll likely have 5–10 (less substantial) discoveries in the following tests.

Because I would only be working with a few artists, I wanted to be there in person to listen to their thoughts, take notes, and ask questions.

I put a do-not-disturb sign on the door and sat down with some artists over a couple days.

The prototype was comprehensive enough to let participants explore. Assigning specific tasks wasn’t necessary for this test. And getting users to explore could give me unbiased insight into their first steps, first behaviors, and first impressions of the prototype.

As a backup, I did have a list of tasks. In case the artists didn’t explore fully. But I didn’t have to refer to those questions even once! All three testers were keen to discover every feature. Except for settings. Settings are boring.

Use your observations to improve the experience

As I hoped (and simultaneously didn’t hope) there were a number of friction-points the artists found.

For every common problem, there are solutions, and there are expenses. With each problem, I suggested a solution and the posited the cost to solve it. Cost, meaning the amount of time to solve it.

It’s exciting to find issues early! The cost would be hundredfold to fix them in development. Frank Lloyd Wright put it better when he said, “you can fix it now on the drafting board with an eraser, or you can fix it later on the construction site with a sledgehammer.”

Observation A: Visual people care about visual things

My initial onboarding artwork was pretty. Thanks to the humaaans design library from Pablo Stanley.

However, every participant saw it as too sleek or corporate. One artist had a particular vision I enjoyed. He said “it should feel more empty… more like a blank canvas that I can use.” His idea lined up with brands for many products Jan uses.

Observation B: Less is more

It turned out the research-focused boards feature wasn’t well received! Unexpected! Two out of three participants found they could do everything they needed with the studio log feature. And the other participant said they only research at their computer.

They also found it unclear whether boards should appear in their calendar. It didn’t fit as well as other features.

Cutting the boards feature altogether was the clear take-away.

Observation C: Don’t break the pattern

Each user found the same problem: they would start making a note, add attachments, and then have to navigate Back to making their note. They didn’t know if Back would save or lose their information.

It had me scratching my head… the pattern aligned with other iOS patterns. In your iOS settings menu you would change your roaming settings, then return Back to your settings menu. But despite being consistent with the iOS system, it wasn’t internally consistent. It was the only instance of this pattern in the app!

I added a Done button. The user wouldn’t lose their attachments by going Back. But they could have the confidence of completing their note after adding attachments.

Observation D: People want to add things in context

The “quick add” button at the bottom caused some trouble. It turns out that while users could figure it out, it didn’t make sense to them that the button was view-agnostic. It didn’t make sense to add anything from anywhere.

The solution was a context-specific, top-right corner, add button. It matched the iOS system better, too. Jan could now only add notes from the notes section, tasks from the tasks section, and either from the calendar.

Observation E: Watch your language

Two participants found it unclear that notes would wind up in the studio log.

The context-specific menu would help, but simplifying the language would help even more. Just as tasks would go in Tasks, notes would now go in Notes. Clear.

Real research adds real value

The revised prototype was a dream app for Jan. Each interviewee and usability participant was eager to see it built. Always a good sign. It wasn’t uncommon to hear “when can I use this?” No sales pitch needed.

Users could see the value immediately. But, it took strategic research, with real people. And the product sells itself.

← Back to Projects