Today, I got rejected.

Well, damn.

Today, I got rejected for representation by an agency that manages, among other things, UX designers. Their rejection was swift and merciless:

"While your profile meets some of our requirements, currently we feel you are not a fit for the type of work we cater to. We would suggest you to improve the presentation of each project and try to showcase them in the best quality possible, your presentation is as important a step in the design process, as the work itself. We also look at your knowledge with the latest design trends, accessibility issues, and color palette, as well as your design process as a whole. You may reapply in 3 months."

How could this happen? I know the design process is important. Of course I keep up to date with the latest trends. My color palettes are extensively thought out, down to the exact shade. I feel confident that I am, in my day to day work, the shiz. So where did I go wrong?

Then I looked back at what I sent them. What I didn't say hit me like a mack truck. I've lamented for so long that I don't have the amount of support I need. I wear three (sometimes more) hats and play the strategist, product manager, designer - hell sometimes, even the developer. But that was no where in my portfolio. I kept it clean, professional, and selected just a few pieces of the process. I listed some of the clients' challenges, but none of my own. I put so much of my soul into the work I do, but there was no way for a stranger to see that in my case studies. They just aren't detailed or human enough. I see where I went wrong.

My mission now is going to be a long-game. It's not going to happen overnight, in fact with my current workload I'll consider myself lucky if I finish it before my three month pseudo-probation is up. It's an investment I desperately need to make though, and I intend to document the entire thing.

Baby Step One

I knew I needed to treat this minor setback as one of my UX challenges. What am I trying to solve? What assets do I have? Where are my challenges, and my "unfair advantages"? What's the market like? Who else is out there, and what do they do?

My first step was to research case studies by UX designers, some who I found myself, and some who actually did pass the test and were represented by the agency I am trying to join. What do the pros include in their case studies? What I found was that there seems to be no right way to do this. There's no formula or template, and I like my formulas and templates. That's cool, I can fix that. Here's a stream-of-consciousness list of thoughts and ideas that I gathered from my research:

• It can be a good idea to separate case studies for the main project and some key individual features.

• Display technical diagrams like sitemaps and technical specs. If these are proprietary, edit them a bit or white out some key elements.

• Show the process of a single screen from sketch to wireframe.

• Show the differences in states and experiences for different stakeholders.

• Include the short, individual interaction videos supplied to developers.

• Include the boring stuff like the weeks spent analysing current flows.

• Include before / after comparisons of screens that were redesigned, even if (especially if) you didn't do the before.

• Personas are a must for each project. I admittedly rarely get time to do nice ones, but that's an area I could dedicate some time to.

• Demonstrate the process with charts and graphs of the design process and software lifecycles.

• Include a project timeline. My deadlines are usually insanely tight, this needs to be demonstrated in the case study itself so everything is seen in context.

• Include better descriptions of the companies I've worked with. I've got some big names on there, don't hide them in a little logo.

• Call out specific tools used in the process. It matters when you use Photoshop vs Illustrator vs Sketch, etc.

• Spend more time on the challenges and briefing that happens before the project even starts.

• It could be a good idea to have a section dedicated to how I approach each step of the design process, combining examples from each individual case study.

• I think I'm going to need a copywriter. Those blocks of text are not my area of expertise, to say the least. Even this blog is mostly in bullets.

• Call out what the deliverables were, and how I delivered against each one.

• Include quotes from the specific client when available.

• Discuss how the user is outside of the digital realm. Show that your solutions are connected to their daily lives.

What now?

So here's where today's story ends. Personally, my next step is to perform a pretty extensive audit of what I've been up to the last five years, and gather all of the stats, docs, research, whiteboard photos, mockups and scraps of paper that show why I do things the way I do them. I've got a hunch that something interesting is going to emerge from that. Stay tuned, internet.

Want to keep up to date with this project, share your own experience, or offer some some words of encouragement? Follow me on Twitter @ashleymarinep!

Sample UX Interview Challenge

This morning I read a blog post by London digital recruitment agency Zebra People that couldn't have had better timing! As they stated, "the majority of final stage interviews now require UX Designers to carry out a task at home and present to the interview panel." I recently hired a Jr UX designer and did the same. Questions like, "What process do you follow?" don't cut it because you end up getting the same answers over and over again. Often the in-person interview process itself is mostly about determining if you can work with this person day-in-day-out. To assess how they apply their skills though, you need something a little bit more interactive...

I'm a major stickler for "no free work" as a freelancer so I would never ask someone to break my own rule. Instead of asking them to solve a real problem or redesign something on my own products, I came up with a fake product for a fake client that they needed to design from scratch. Here's the brief:

Following your UX process, please design a product that meets the following business requirements:

1. The client needs a mobile application.

2. Users must be able to log in with their email address and password.

3. When inside the application, users must be able to perform only one task - tapping a button that says "Tap Me"

4. Users must be able to view historical data on how many times they have tapped this button in the past.

5. Your deliverable may be in the form of sketches, wireframes, mockups, prototype, technical specifications - whatever documentation you feel represents your personal skill level. There is no minimum or maximum that you must provide.

6. Please use a maximum of 90 minutes for this challenge.

I gave this assignment to the three people who passed the initial interview rounds. Here's what the responses that I received told me about them:

• Did they include all the necessary account management pieces (such as Create Account, Reset Password, etc.) that come with email login?

• Did they create a true onboarding flow?

• Did they account for differences in user behaviour between iOS, Android and other platforms?

• Did they offer any documentation(such as object tables, database schema suggestions, etc) which could be passed straight on to developers?

• Did they make a single assumption about how historical data should be viewed, or did they instead create a system that scaled?

• How much did they focus on UX strategy vs UI design?

• Did they address the challenges caused by knowing nothing about this client or their purpose for the app?

• Did they make any alternative suggestions and back them up with justification?

In the end, the designer I hired passed with flying colours and has been a huge asset to our office. We were able to bring her onto the team with confidence that she would be able to dive in the deep end with us.

Check out Zebra People's post for other samples of UX interview challenges.

Got another suggestion? Catch me on Twitter @ashleymarinep.

A Look at Visualisation

Data visualisation, graphs and charts can be a big challenge in a project. Sometimes it's overwhelming to even know what insights to display, let along how to display it. Below are some tips and tricks I've picked up along the way.

Planning

While planning charts, I start with questions like:

• Who is looking at this data?

• What is most important to them when viewing this data?

• What do they already know or assume from the data?

• What pieces of the data do they not care about?

Investigating why anyone wants to see this data is the key to finding that perfect spot of "Informative" which lies somewhere between confusingly vague and confusingly complicated.

I begin the wireframe stage with the most important ifo largest and closer to the top, down to to the least important info smallest and at the bottom.

Then I start looking at each piece of insight and asking why I'm showing that particular piece to the user. There are usually only two reasons to show data to a user:

• Explore: Show them a large dataset and allow them to draw their own conclusions.

• Explain: Show them a single conclusion within just enough context of a larger data set.

Special thanks to Data Visualization Best Practices for this great tip.

Labels

When it comes to axis labels, it's important to consider how much the user already knows and assumes. Detailed is great...

...but, in situations where you have a particularly tech-savvy user or the audience already knows/assumes certain things about the data, you might be able to go for a cleaner look.

Note that in the first sample, even though a large number of axis labels are shown, interior labels are a lighter font both in weight and colour. Charting axis labels only exist to anchor the viewer. They shouldn't compete for attention.

In some cases, it may even be appropriate to remove them all together and display the values in a different context:

The same principles apply even when flipping the data on it's side:

Short on space? Axis labels can be condensed within bar charts, for example in smaller highlight areas:

Special thanks to Effective Dashboard Design: Why Your Baby is Ugly for this data set.

Numbers

As in most things, keep it simple.

Bad Numbers

Good Numbers

Again, if you don't need it, junk it!

Instead of creating long tables or lists of data, bullet graphs can be a helpful visualisation.

The Line Chart Danger Zone

Having worked quite a bit in design around Health, I can tell you: It's probably best to apply a healthy dose of suspicion around line and area charts. The problem is that they often show stages in between two data points which didn't really exist. When in doubt, I default to bar charts because they don't lie. I'll show you what I mean...

Data points across a bar chart are safe. We can see the days that have available data and what the exact input value was on that day.

Now, place these data points on a line chart. As you can see from the red line, we've started to hint at results that aren't real.

Add a Dribbble-worthy layer of smoothing and shading and now we've created even more of a "curve" which didn't really happen.

Of course, how careful you need to be depends on what you're displaying and how high the stakes are. If you can afford to sacrifice a little pin-point accuracy for beauty, then go for it.

Interaction

I'm a big fan of interactive charts where a user can hover over specific data points and view tooltips (do we still call them that?). When designing this, the data line and point should be clearly isolated, like so:

Lines and shading can be used to show alert lines, benchmarks, averages, etc.

I recently had a client who needed to be able to add values to a scatter plot which were un-verified. We came up with this solution of solid vs outlined values:

Similar to hovering over tooltips, I try to make legends interactive when possible. Legend and data are isolated clearly together.

Colour

What good would an article about charting be without some talk about colour?

So, here's the deal: We all know the basics. Green is good, orange & yellow need attention in some way and red is something scary.

Developing a colour palette is a topic that needs its own blog post, but as long as you keep basic colour associations in mind, you're going to be just fine.

When it comes to anything that could be referred to as "colour coding"...

https://twitter.com/ashleymarinep/status/705049544233525249

Do you need to colour code? The answer is "No" more often than not. (I once had a client ask me to colour code all of the individual features in his app. I had to do a set of mockups to show him why looking like a rainbow sneezed across your entire app is a user experience no-no).

One thing that is really important is to make sure that you take into account is accessibility for Colour Blindness. Personally, I use the Spectrum Chrome extension to test out colour combinations.

Below are some simple examples of how colour can be used in charts.

"Feeling" the Weight of Your Data

The final thing I want to talk about is the concept of helping users "feel" their way through the data. Check out The World's Most Boring Data Set. In this use case, high numbers were bad and low numbers are good.

Snooze-fest... but see what happens when we turn those numbers into graphics that use size, weight, colour and opacity:

The eye is automatically drawn to the "good" spots and a user can instantly feel whether this data set is positive or negative.

Fin.

That's all I've got for you today! Have a suggestion, idea, or view to share? Catch me on Twitter @ashleymarinep.

When Individual App Features Become a Larger-Than-Life Monster: Auditing a Franken-Brand

I recently started a project with a client who was managing a successful suite of web & mobile applications, all under the umbrella of their digital brand guidelines. This was a small team and resources were tight, so managing that many apps over multiple swimlanes was threatening to create a monster soon - a monster I refer to as the Franken-Brand.

What's a Franken-Brand?

Franken-brands happen when apps are built next to apps, and no high-level overview of the brand as a whole has happened in an extended amount of time. This can happen for many reasons. Most commonly because guidelines are implemented faster than they're audited, because we don't know what we don't know when we initially write them. Another reason this can happen is that resourcing is so limited that only one or two people are overseeing an entire suite of applications, so their expertise is only applied on the surface. App-specific requirements are applied on top of general guidelines, and never make it into the official document. This "if it ain't broke, don't fix it" environment is classic in a small team.

What is a Franken-App?

Similarly, Franken-apps happen when features are built on top of features, but high-level overview of the full user experience is neglected. This usually happens when there are multiple stakeholders spread across an application and dedicated product pros are spread too thin. Sometimes, depending on the workflow, initial feature specifications are written side-by-side instead of consecutively, so inconsistencies are naturally created. We work in a field where there are a lot more combinations of "right" answers than "wrong" answers, so two teams may come to entirely reasonable translations of a guideline, but they don't match.

What's to be done about it?

Well, in the case of my client, we're going to form an angry mob - kinda. This week, I launched a full audit of all states of all screens of all apps, after which the entire suite will be reviewed by myself and some other contracted UX pros. Bringing in new talents that I've not worked with before exposes us to other areas of expertise, and ensures that we remove bias from the redesign process. Commonalities between features will be identified and brought into harmony as we develop short-term and long-term specs for change.

After that, the ecosystem-wide guidelines will be updated, and the new version will be used going forward until the day when, inevitably, it's time to review again.

Have a tip on how to avoid the Franken-Brand syndrome? Tweet me @ashleymarinep!

49 Phrase Inspirations for Rewarding User Engagement

When done right, proper gamification of actions within your app can increase feature engagement, give you influence over your user’s actions, and even increase brand loyalty. With so many companies embracing these methods, it’s no wonder we see the same things over and over again. The concept still remains, but it’s vital to stay fresh and give users real value through gamification. Badges and simple awards aren’t enough to keep users coming back. Below are some concepts to get your creativity brewing!

When you’re guiding your user through a static process:

1. Acts

2. Adventure

3. Deeds

4. Degrees

5. Evolution

6. Graduation

7. Journey

8. Levels

9. Notches

10. Phases

11. Points

12. Race

13. Ranks

14. Rungs

15. Stages

16. Steps

When you’re prompting your users to complete ongoing actions:

1. Assignments

2. Commissions

3. Duties

4. Errands

5. Exercises

6. Functions

7. Gigs

8. Milestones

9. Missions

10. Projects

11. Sprints

12. Tasks

13. Works

When you’re tracking or rewarding a user’s achievements:

1. Adventures

2. Awards

3. Boosts

4. Boss Fights

5. Breakthroughs

6. Decorations

7. Easter Eggs

8. Energy

9. Gifts

10. Goals

11. Gold

12. Growth Spurts

13. Health

14. Honours

15. Milestones

16. Power Ups

17. Stars

18. Strides

19. Trophys

20. XP

Got other ideas? Join the discussion @ashleymarinep.