Fixing the Information Architecture of my site

Last month, in What’s wrong with my site, I picked three small improvements and assigned them each to a different “Future Shane”.

fix the Information Architecture (IA) of this site. If someone comes to and reads an interesting article, it’s difficult for them to explore. That’s a problem because there’s over fifty great articles that they might like.

June Shane, June 2019

So I (July Shane) got out the sticky notes and tried to make sense of the content of this site.

Step 1: Write all titles on sticky notes

Room with sticky notes on the wall
One sticky note per post, arranged by date

As I was writing the title of each post onto a sticky note, I put them up on the wall in chronological order. It was very pleasing to see that I have had no months without a post in over 2.5 years.

Room with some sticky notes on the wall and others scattered on the floor
One sticky note per post, arranged by gravity

What wasn’t pleasing was when half my sticky notes fell onto the floor.

I think many years ago they came out with Super Sticky notes which seems like a complete contradiction of the value proposition but I think it’s just an acknowledgement that the original formulation fell off more than we’d like. I don’t think of them as Super Sticky, just the proper amount of sticky for most uses.

Steve Portigal, Dollars to Donuts podcast

Next time, I’ll get the Super Sticky notes.

Step 2: Arrange by topic

I then moved all of my sticky notes to the floor so that gravity could work for me instead of against me. I grouped the blog posts by topic and tried to give meaningful names to each group.

Sticky notes arranged on a hardwood floor
Grouped and labeled sticky notes; this time on the floor

Step 3: Implement

After a couple more iterations, here’s what I came up with.

Screenshot of navigation menu with 6 items: About me, UX strategy, UX tactics, Data visualization, Programming, and Other ramblings
My new menu

For comparison, here’s the old one.

Screenshot of the main navigation of the site. 

    About Me & Contact
        Google Apps Script
        Google Forms
        Google Sheets
    Oddly Specific: Various Notes and Collections of Links
    Getting Started in UX
Search bar
My old menu

I still don’t love it but it way better represents what I write about most. It also is simple enough to fit into a top-level menu instead of a hamburger menu, which I’m sure August Shane will appreciate.


What’s wrong with my site?

In late-2015, my now-wife and I decided to move away from the city we’d lived our whole lives in. I applied for tons of development jobs in London before the move but hardly heard back from any of them. I figured it was because I had nothing to show online and was 7000km away.

The history

So I went to WordPress and grabbed the first decent WordPress theme that I could find. I then published a handful of articles, including Using boost::bind and boost::signals2 to Automatically Propagate Signals. These early posts were a great exhibit of my technical knowledge. They also lulled all readers into a deep, restful slumber.

Not long after those two posts, I found a job. Coincidence? Yes. Because that was also around the time that I actually made the 7000km move to London. But my online presence couldn’t have hurt!

Since then I’ve written fifty more articles. These articles have shifted, along with my career, from engineering to design.

But I haven’t changed the design of this site at all.

A designer’s site should be designed

It’s bugging me more and more lately. C++ experts are almost expected to have hideous, unusable blogs. But a professional user experience designer? No. This will not suffice.

So now I’m going to commit to improving it… Actually “I” am not committing to it. “Future Shanes” are.

July Shane: Information Architecture

July Shane, you’re going to hate me for this, but you’re not here to defend yourself. I’m volunteering you to fix the Information Architecture (IA) of this site. If someone comes to and reads an interesting article, it’s difficult for them to explore. That’s a problem because there’s over fifty great articles that they might like.

Look at this main menu.

Screenshot of the main navigation of the site. 

    About Me & Contact
        Google Apps Script
        Google Forms
        Google Sheets
    Oddly Specific: Various Notes and Collections of Links
    Getting Started in UX
Search bar
The current site menu as of June 2019. There’s a lot more on this blog than the Programming and Consulting that I posted about in 2015.

So get out the post-it notes. Wrap your head around our content. Group it, tag it, categorize it. Then update this menu. By the end of the month, I want a coherent, usable hierarchy of content. It should highlight your recent work as well as the early stuff. And I want you to blog about it.

If anyone is reading this beyond July 2019 and the menu hasn’t changed, please shame July Shane. Use a tweet or get creative.

Update: July Shane did his job, just in time! See Fixing the Information Architecture of my Site

August Shane: Usability

I don’t know about you August Shane, but I don’t hate the hamburger menu. In certain cases, it can fine. This site is not one of those cases. Especially when you’re viewing on a big desktop web browser or even a tablet. Why bury July Shane’s beautiful categories of content under three boring lines?

The current site banner. It’s clean, but not intuitive or usable.

What I DO hate, though, is the align-right symbol floating opposite of the hamburger menu. Can you guess what’s under there? Align all the words on the page to the right for some reason? No. It’s to “follow” this blog.

Anyway, August Shane, all I want you to do is get rid of the hamburger and the right-align buttons. Use words instead. Then blog about it.

If anyone is reading this beyond August 2019 and the banner hasn’t changed, shame August Shane. Here’s a template tweet you can use.

September Shane: Have fun

I’m not always a jerk to my future self. September Shane, your job is to have fun improving this site. Maybe get into the code and make it so is the actual domain of the blog instead of a redirect. Maybe use IFTTT to post all articles to Twitter and LinkedIn automatically. Maybe add alt text to all images to make the content more accessible.

Whatever you choose to do, have fun and don’t forget to blog about it! Oh, and update this article with a nice happy ending for this three-month-mini-makeover.

Hey reader, are you from October 2019 or later? Is there a happy ending to this article? If not, shame that slacker September Shane s’il vous plaît.

Usability testing is fun

Last week, a colleague and I ran an eight-person usability study with a big customer. We started at 6:30, so it was a super-early, super-long day.

Iterating on the product AND the process

Yes, it was exhausting, but I love this stuff. You take your best guess at a design then you put it in front of a bunch of people. Then they struggle with it and you make it better. That iteration what research is all about.

I also love how we’re iterating on the process itself. November was the first time I’ve traveled for usability testing. Yesterday was the first time I’ve done remote usability testing with clients. It was also the first time we’ve hosted a viewing party where people from all over the company could tune in and see what usability testing all about. Oh, and it was the first time we had a client representative observe all of the tests we ran. So many leaps forward!

What’s next?

When it comes to process, I wonder what is next for us. Maybe a focus on quality? For instance, we could start to critique each other on body language, tone of voice, note taking, and more. Or maybe more logistic stuff, like making scheduling better. Or smoothing out the participant recruitment pipeline.

But for now it’s good to keep enjoying it, keep learning, and keep iterating!

P.S. It was fun last time, too!

I just checked my notes from the November usability testing trip, and I had a similar rush of enthusiasm:

I’m exhausted.

Man is it draining to do this much research. It is not easy to sit in a little meeting room for a full eight hours, actively listening while thinking ahead and trying to be self aware enough not to be biased. Then summarizing findings and prepping for the next day’s tests with customized prototypes and doing it all again. That’s hard too.

But I love it.

-My own notes after a full week of usability testing

Feature photo stolen from @jdorn. Thanks, friend 😈!

Using Airtable to store research nuggets

I started at Solium in January. They did a full day of usability testing for World Usability Day in the previous November but hadn’t yet got through analyzing all of the videos. It’s a small team and other priorities got in the way.

Around that time, I listened to a Tomer Sharon interview on Mixed Methods, a UX Research podcast that I highly recommend.

In that interview, Sharon discussed how UX Research usually ends up in reports that are read once then forgotten, and how non-researchers make observations about users every day that aren’t documented.

The answer?

Track every observation, or nugget in the same place. The nugget is the atomic unit of research, not the report.

This prevents research from being forgotten, it gives transparency to how research is interpreted, and it “democratizes UX” by potentially allowing non-researchers to contribute and search research findings.

Here’s what I did

So I copied Tomer Sharon’s “Polaris UX Nuggets” base.

Screenshot 2018-06-21 06.08.34.png

Tomer Sharon’s Polaris UX Nuggets database- available for you to copy!

I knew that this wouldn’t be adopted by my team if it was too much work, so I simplified. And simplified some more. Including:

  • Removing provocations, journeys, acts, scenes, props, and sets
  • Combining “Experience Vector” and “Magnitude” because they’re two measures of the same thing and because “High Neutral” doesn’t mean anything. Thanks Cong for suggesting this!

Then tried it out.

Then documented.

Then tested it with a teammate.

Then moved our videos from Dropbox to a private YouTube channel and added a function to timestamp the nugget url. Thanks Jason for suggesting this!

Then tested it with another teammate.

Then simplified by creating a simple form with only 3 mandatory fields. Far more efficient and less overwhelming than dealing with a giant database.

Then tested it with my manager. Thanks Stuart!

Then simplified.

Then assigned all remaining videos to be nuggetized by the team.

Meanwhile we’re doing more usability tests and nuggetizing those as we go.

The Results

This has already come in handy twice.

First when my coworker Jason was considering adding a hyperlink in a certain place, I expressed my doubts. Luckily, Jason remembered some recent observations and within a couple minutes he had pulled up Airtable and showed me two clips of real customers trying to click the text that he wanted to hyperlink. Damn you Airtable! I gave you life and you’re already proving me wrong!? Seriously though, these observations would not have been found so easy if they were just buried in a usability report somewhere

Second, when we were having a mini design sprint on one problem area in our dashboard, I was able to quickly pull up several short video clips of real customers running into usability issues in that area. It’s great that this database can essentially provide a highlight reel for anything you need!

Next Steps

Going forward, the UX team at Solium is continuing to evaluate Airtable this will continue to evolve, but so far I’m very grateful that Tomer Sharon was sharin’ his database! #punIntended #dadJoke #badJoke

Appendix: How to generate timestamped Youtube URLs

For all the formulas I used, make a copy of Youtube url generation on airtable. Using that, you should be able to get from a youtube share link to a timestamped start/end youtube url.

Example youtube share link:

Nugget timestamp: 24:00-24:13

Timestamped youtube url:

Match Debt: When your system and the real world don’t align

Twenty-two years ago, design legend Jakob Nielsen published 10 Heuristics for User Interface Design. These ten tips are just as relevant now as they were in the early days of the internet.

I consider them my ten commandments when it comes to designing software. In fact, this was the one and only thing that I displayed on my cubicle wall at my previous job.


My ten commandments (Forgive me father Nielsen, for I have sinned)

Anyway, the second heuristic on the list is:

Match between system and the real world

The system should speak the users’ language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.

In other words, you want to make your product come as close as possible to the mental models of your users. In a perfect world, all products would closely align with how customers actually think.


The heuristic “Match between system and the real world” means that your product should align closely with the mental models of your users

Unfortunately, it’s not a perfect world.

In reality, there’s always a gap between how the product represents things compared to how the user actually thinks about them.


In reality, there’s probably a gap between your product and the mental models of your users

Actually, it’s often quite a large gap.


There may be a significant gap between your product and the mental models of your users

At my previous job, an established financial software company, the RTFM test revealed a feature that caused a lot of support requests: user access control. After speaking with some customers, we noticed that they were using different words than we were. What the system referred to as Access Areas, they called Functions. Also, the interface for user access control wasn’t consistent with the rest of the system. Our customers were used to using Excel-like tables to configure and view things, but this feature had a series of listboxes and dropdowns that were much less familiar or flexible. For this feature, there was definitely a gap between our product and the mental models of our users.

The Match Debt

Having this gap is not a huge problem (users tend to “satisfice“, settling for “good enough” solutions instead of fully understanding all options), but it is a cost. A cost that shows up in customer support, bug fixes, and worse: lost sales. I call that cost the Match Debt, because much like technical debt, the decisions you make today can make future development more expensive, like paying interest on a loan.


The Match Debt is the size of the gap between the system and the real world; the bigger the gap, the more money you’re losing

For our user access system, the Match Debt showed up most visibly in the form of calls to our support team. It also meant that the feature was hard to maintain. It may also have led to lost sales, though that is much harder to mention.

There are really only two ways to pay off Match Debt.

Educating your users

Firstly, you can try to move the users mental models closer to the way the product works via customer training and documentation- let’s call this education.


Education attempts to move your users’ mental models closer to the way your product works

Our user access system had thorough, well-written documentation, which I’m sure helped some of our customers, but users don’t read!

Learning about your users

Alternatively, you can try to move the product’s design closer to how the users think. This can be done in many different ways, including researching your users, designing solutions to their problems, testing these solutions, and more. But for simplicity’s sake, let’s just call this User Experience, or UX.


UX attempts to change your product closer to your users’ mental models

This is what we did when we redesigned the user access system. The new design uses slightly more familiar language and presents it in a way that’s consistent with the rest of the product. It’s nowhere near perfect, but now the Match Debt is lower, meaning that we’ll probably have fewer support calls and slightly happier customers than before.

It’s not you, it’s me

Both education and UX do the trick in reducing Match Debt, but from a customer’s perspective, UX is a whole lot nicer because it means that the product is doing the work, as opposed to the customer having to do the work. UX puts the onus on the few people who develop the product instead of the many people who use the product.

UX is the product team telling the user “it’s not you, it’s me”, then actually doing something to fix “it”. Isn’t that the way it should be?

Sure, this is a gross oversimplification, but this is why I love UX so much. It pays off Match Debt by aligning the product (and in fact the whole organization) closer to the users’ mental models.

It’s hard work. But it’s worth it.

Quotes from Interviewing Users by Steve Portigal

I just finished reading Interviewing Users. It’s one that has been on my list for a long time, probably because I loved Steve Portigal’s Dollars to Donuts podcast. It did not disappoint.

It was a great read for me because I’ve done enough user research to have some experience to map to, but not so much that I knew everything in the book.

Here’s a collection of quotes from the book that I found valuable, organized by theme.

Preparing for interviews

Portigal first walks the reader through what to do before interviewing users.

“At the outset of a project, make the objectives your initial priority.”

Interview 6-8 stakeholders (yes, you interview the team even before you interview the users!) to see what they want to learn. Sift through the politics and agendas and try to get everyone on the same page as to what the objectives are. Find issues such as

“…hypotheses masquerading as facts, aspirations, and mass hallucinations… resolve those issues as tactfully as possible.”

Prepare a field guide but

“this is not a script. It reads very linearly, but it’s really just a tool to prepare to be flexible.”

Research scheduling

Once you’ve agreed on the objectives and recruited participants, schedule two interviews a day or so. But why not more?

“Quality work doesn’t come from being rushed, exhausted, harried, or overwhelmed. Interviewing is hard work. You need time between sessions to reflect.”

And while it’s tempting to save time or resources by using Skype or a phone call or getting users to come to you, go to where the users are.

How many people should go to each interview?

“I find the ideal size for the field team to be two people: one to lead the interview, and one to back up the other person.”

Documenting the interview


Prepare a shot list before interviews that lists the photos that you want to take.

“Even if you’re capturing imagery using video, still pictures are essential.”

“Even though they agree to the use of photography when they sign your release, let the interview settle in before you start taking pictures. You can verbally confirm that it’s okay before you take your first picture.”

Taking notes

Note taking is okay but no one writes fast enough to capture everything and

“you must maintain eye contact while writing.”

If taking notes, just write the facts. Not judgements. But if you must interpret,

“it’s easy to lose track of what you were told versus the conclusions you made, so take care in how you document the two.”

As soon as possible after each interview, write a top-of mind summary.

“Allow time for debriefing after each interview… The longer you wait, the less you will remember, and the more jumbled up the different interviews will become.”

Video or audio

Video or audio recording is the only way to capture everything the participant says.

“Keep your eyes and brain in interview mode until you are fully departed.”

“consider keeping your recording device on, even if it’s packed”

because of

“the “doorknob phenomenon,” where crucial information is revealed just as the [therapy] patient is about to depart.”

Interview technique

Portigal offers lots of tips about actually conducting the interview.

They’re the expert

“make it clear to the participant (and to yourself) that they are the expert and you are the novice.”

“Asking that person to play the teacher role not only reinforces the idea that she is the expert here, but it also can make it easier for her to articulate the details you are seeking.”

Invite honest criticism

“if you bring out a concept by saying, “Here’s something I’ve been working on…” you’re activating a natural social instinct that will diminish their comfort in being critical.”

Building rapport

Start with general (easy) questions to get them warmed up. It will feel awkward and uncomfortable but accept and break down the awkwardness by

“accepting, acknowledging, and appreciating her responses.”

“Try to construct each question as a follow-up to a previous answer.”

If you change topic, “signal your lane changes”.


Once you’ve built rapport, you will reach a tipping point from question/answer to question/story.

“Stories are where the richest insights lie, and your objective is to get to this point in every interview.”

Use their language

“build rapport by accepting the terms the participant was using rather than trying to demonstrate credibility.”

“Don’t correct her perceptions or terminology if the only outcome is “educating” her. Advocate for her, not for your product.”

The interview isn’t about you

“[Only] talk about yourself if doing so gives the other person permission to share something.”

To dodge questions asked by participants,

“Do the Interviewer Sidestep and turn the question back to them: “Is that important to you?” “What would you expect it to be?””

Question Types

Ask about sequence, quantity, examples. Ask for exceptions, lists, relationships. Clarify comments, language/ code words, and emotional cues. Ask them to teach, to compare, etc.

You want to know about their needs. But you can’t directly ask about their needs. So you ask them indirectly.

“There’s a difference between what you want to know and what you ask.”

On participatory design

“My aim with participatory design is to give people a different way to talk about needs, where the solutions stand as proxies for those needs.”

You don’t actually have to implement any of these designs.


“One way a novice interviewer tries to counteract nervousness is by preemptively filling the silence.”

“Ask your question and let it stand…. After she has given you an answer, continue to be silent.”

Improving as an interviewer

Practice interviewing. Even in daily life.

“Cultivate a style of interacting socially that emphasizes listening, reflecting back the other person’s comments, allowing for silence, and so on.”

Also, review your interview recordings with a critical eye like a football coach would review game tape.

“ask someone to come along to your interviews and get his feedback. Also ask for feedback from the rest of your field team.”

Other tips include teaching others to interview and even taking an improv class, because that will improve your abilities of thinking on your feet, accepting awkwardness, and “going with it”.


Analysis and synthesis

After you’ve finished all of your interviews, follow a procedure like this to squeeze as much learning as possible out of your research:

  1. Divide and conquer: “get your data in text form and divide it among the team.” Each team member reviews and summarizes one or more interviews.
  2. Summarize for the team: “The group should then reconvene and present each interview as a case study.”
  3. After all summaries, recap: “Discuss each interview briefly, and then create a sticky note that summarizes the key point of that interview.”
  4. Group findings: “create groupings. You may want to start with the categories from your topline and add to them.”
  5. Prepare the report: “the Presentation of Findings, which is the main research deliverable.”

User research and organizations

Interviewing is a good way to increase a company’s UX Maturity. It…

“starts to drive shifts in the organizational culture”

“position yourself in your organization so that interviewing customers is an integral part of how you work.”


“The most impact for the least effort comes from your colleagues joining you in the field.”

For organizations with high maturity, research informs design but also exposes

“new opportunities for teams to embrace a user-centered approach to their work.”


I really enjoyed this book and I’m sure I’ll continue to refer to it (and these notes) for years to come!

The RTFM Test

As your team improves its UX maturity, it can be easy to be overwhelmed by all of the possible ways that you can improve your product.

One good place to start is the RTFM test.

How to do the RTFM test

It’s simple. Ask your support team:

What area of the product gets the most support requests that don’t end up in bugs being logged?

In other words: Which areas does the support team most often find themselves telling the customers to RTFM (Read The Freakin’ Manual)?

Or worse: Are there any areas that the support team has to keep repeating itself because they’re not even covered by the manual?

That is where you start. That’s the lowest hanging fruit. Those are the usabugs. Fix those and you’ll free up your support team to deal with real bugs.

But how?

Now that you know which area of your product is the biggest RTFM offender, there are many ways you can improve it. Let’s turn to Jakob Nielsen’s classic Ten Usability Heuristics for inspiration. Specifically, number ten:

Help and documentation

Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large.

There’s a lot in there, so let’s break it down:


If at all possible, get rid of the freakin’ manual. “It is better if the system can be used without documentation.” This should be paired with user research such as usability tests to make sure you’re solving the real underlying issue.

For example, maybe the product uses a list of cryptic codes that the user must look up in the manual in order to understand what they mean. If so, provide that information on-screen instead.

Improve your documentation

If you can’t GROTFM, then follow Nielsen’s hints on how to improve your manual.

  • Provide easy-to-use search functionality
  • Center the documentation around user tasks, not system areas
  • Provide step-by-step instructions for accomplishing those tasks
  • Keep it short

As above, use user research to guide and validate your work on the documentation of your system.

Try it out!

It seems obvious in hindsight but before I redesigned the user access system at my previous company, I had dabbled with dozens of other ideas for improving the product. Sure, I was able to find lots of areas of the system that violated usability heuristics or clearly didn’t work as expected, but only when I discovered the RTFM test was I able to find something that was actually valuable to the business and to our users. The RTFM test allowed me to easily prioritize all those opportunities for improvement.

Organizing Documentation with Card Sorting

We use Confluence at work for internal documentation. It’s kind of like Wikipedia, but only us developers can see and edit it, and the articles are things like How to set up Server x, or How to Test y.

I love it because we previously used long email chains with the answer buried deep within, mixed with dusty old word documents locked into source control. Confluence feels so much more lightweight, nimble, and searchable.

The Problem

Unfortunately over time it’s become a bit of a mess. We have over a hundred pages but there’s not much rhyme or reason as to how to find them. Confluence does have a search function but, believe it or not, people still browse. Also, if you’re adding an article it’s hard to know where to put it.

The Solution

So I decided to run a card sort exercise with my coworkers. My goal was to understand how they thought about these topics then organize the articles in a way that matched that as close as possible.

I scheduled a lunch and learn, invited the whole development team, and…

(Almost) No One Showed Up


A photo taken at my first attempt at a card sort workshop

Just one of my coworkers and my manager came. I should know by now that now all developers are as into UX as I am 🙂

Luckily, my manager agreed that this was important enough to schedule in and make mandatory, so a couple weeks later, the workshop was on!

The Actual Workshop

I hadn’t run card sorts recently, so I brushed up on my basics. The two main rules that stuck out for me:

  1. Run with one person at a time
  2. Never make people sort more than 30-50 cards at a time

I broke both those rules. Because I only had a one-hour workshop, I had everyone do the sorting in three small teams instead of individually. Also, because we had 100 articles, I did the sort with all 100 of them.


Team Pink sorts away. See guys? UX can be fun!

After that workshop, each team ended up with several named groups with several cards each.

Analyzing and Testing the Results

I then used a template from Donna Spencer to analyze the results. I’d definitely recommend this template. It’s free and it did the trick.

Each team came up with remarkably similar groups. Based on those groups, I then came up with proposed categories and tested with a quick tree test using TreeJack from OptimalWorkshop.

Photo 2017-03-31, 2 57 27 PM-edited

My attempt at making sense of the card sort results. Paper still beats Excel sometimes.

Based on the tree test, one of the cards was clearly in the wrong category so I moved it. A couple of the others weren’t decisive so I added cross-links, effectively giving those articles two homes instead of just one.


I’m very happy I did this. It was nowhere near perfect but it definitely vastly improved the structure of our documentation, showed everyone which articles were available, and introduced card sorting to the team.

Next Time

If I had more time I probably would have done the sorts one-on-one with my teammates instead of doing everyone at once in teams.

I should have used a smaller representative sample of the articles instead of trying to sort them all.

In other words, I should have followed the basic rules of card sorts!

Oh well! You can’t learn the limits if you don’t go past them every now and then, right?!

How to make a logo, for free, in about 120 minutes

I was skimming through the article “Medium’s best design writing of 2016” when I stumbled upon this gem:

How to make a logo, for free, in about 5 minutes.

I’d been thinking about giving my site a bit of a refresh and I know that visual design is the weakest part of my UX repertoire, so I thought “I have five minutes to spare. Let’s do it!”

9:30- The article says I can use Sketch, Figma, or Illustrator. I briefly poke around the websites for each of those tools and got the best vibe from Figma. Download started.

9:34- Installed Figma

9:36- Figma onboarding

Onboarding is the way that apps show new users around. It’s tough to do well, partly because you don’t want to annoy experienced users by forcing them to click through a guided tour, but you don’t want to leave novice users out to dry by not teaching them anything.

I think Figma did a good job with onboarding- at least for me.

They do the typical “feature tour”, as you can see in the Constraints window on the left, which is nice because it briefly shows you what it can do. Also, they provide a few examples of finished Figma projects- you can see an overview of Google’s Material Design framework in the middle. Lastly, and most interestingly, on the right they have a messaging session.

I think I like this. It feels welcoming. But it’s weird that this Jason character seemingly just wrote me a message, complete with “have a great holiday”, yet he was active 1h ago.

9:39- Finished the feature tour. I’m very curious about “Jason”- is he a chat bot? So I message him, asking about the length of the free trial, just to see if he’s actually there.

9:52- Still no word from Jason.

Finally following through the steps in the “five minute” article. Figma has a billion fonts, but I don’t see any of the “classic” fonts mentioned in the article, so I scroll through one at a time. Feeling dyslexic after staring at “Shane G” in dozens of different fonts. Chose a dozen or two.


50 shades of Shane

I’ll try to narrow my options a bit now.

10:02- Seriously. Really feeling dyslexic. Sometimes when I look, it says “Shnae” or SHENAG. I swear. I should ask Jason why Figma scrambles letters around like that. I think I’m getting somewhere though. Here are my slightly narrowed-down options of fonts.


13 shades of Shane

10:07- It’s like picking a favorite child!!! I want to be professional but interesting. How do I choooooose?!


6 shades of Shane

10:11- Ah screw professional. I’m going with the font called “Text me one”, even though I’m worried that it’s the new Comic Sans and I’ll be judged by all real designers for making this choice.

Okay, 41 minutes in and I’m done step one! So much for a five-minute logo.

10:12- Wow! Jason wrote back! With a detailed and thoughtful response. What a guy! He’s real! (I think.) Turns out they’re still quite new and they’re not charging until early 2017. So far, so good. What a great UX 🙂

10:20- Step two complete.


Stare at this for five minutes and the letters will start changing order. I swear.

10:31- Oh, I was supposed to play with more than just the spacing and capitalization? Okay. NOW step two complete.

All typesetting1x.png

I’m sort of starting to think outside the box a little now.

11:05- Man this stuff is addictive. I had a lot of fun with the logo step.


Initial logos


A few more logos

Time for color!

11:21- Okay, initial colors done!


Initial colors

10:40- After a bunch more experimenting, here’s what I came up with. I really like it, but I can’t say I love it quite yet. I guess that’s the difference between doing it yourself and hiring a pro.


My finished logo (for now!)

Anyway, I think it’s time to get some shut-eye… What do you think, Jason? …Jason?



Ugly yet organized sketching

As a side project at work, I’m currently slowly chipping away at a troublesome area in a legacy desktop application. I’ve done some group ideation (brainwriting) and some usability testing in this area, but I hadn’t had much of a chance to really “sink my teeth” into the interface.

My favorite way to really get to know an interface?


I love sketching because it turns half-formed ideas into tangible things, often exposing flaws that you never knew were there.

I just returned from a trip to Germany and Poland. Anticipating lots of waiting and planes, trains, and buses, I set a goal of 100 sketches over the course of the week.

I ended up with 43.

A little disappointing, but I think what I lacked in quantity I more than made up for in quality.

Now that’s some quality sketchin’!

image 123923953

It ain’t pretty, but it works!

No, not aesthetic quality. They’re definitely not the prettiest of pictures. However, I feel like I made a breakthrough when it comes to how I lay things out.

Number sketches for linking

As you can see in the example, I started every sketch with a number. I only really started doing this because I wanted to know how many sketches I had done, but it had the secondary benefit of allowing me to refer to each idea one at a time and “link” between sketches. It really forced me to keep my sketches and ideas organized.

This was an improvement over my previous sketching binges where I’d just fill up the page with multiple ideas then move on. It also allowed me to branch out and come back to ideas instead of having to choose one at a time.

Pros and cons

Each page starts with a brief intro and often a “Why”. The sad faces show the doubts that I had after creating the sketch. Often, I address these doubts in later sketches. Or at least I try.


Thanks to this slightly more organized way of sketching, I can see myself getting much more value out of my sketches. It’s sort of like writing code. If you don’t put a little effort into making it clear what you’re doing, it’ll probably be incomprehensible to your coworkers- actually, it’ll probably be incomprehensible even to yourself a few months down the road!


How do you sketch? Can you recommend any resources for improving my sketches? Bill Buxton is on my list but are there any others that I should know about? Give me a shout out @sgryzko and let me know!