UI Patterns.

Learn how to “Talk-the-talk”.

Role | Product Designer

Timeframe | 1 Week Sprint- January 2017

The Problem| Being able to articulate and identify UI patterns fluently is one of those qualities that takes time and experience to gather. It is also true that it might be challenging for budding designers to speak with confidence about design concepts they may be familiar with and may have even used, but might not know the term for.

Correctly identifying the three bars that open a side navigation as a “hamburger button” may not make or break an impression you give to employers in an interview. However, getting it wrong might. When it comes down to it of course people are looking for designers who can “walk the walk”. But a crucial part of a designer’s role requires them to adeptly communicate their concepts to a team. Thus, talking the talk.

There are a lot of websites out there that provide various lists and resources of UX/UI terms, but there was still the issue of knowing what designers today were actually saying.

I remember learning from trusted websites what a “KPI” was, just to find out that most designers rarely, if ever cal it that. They may have heard the term in their cognitive science courses, but rather in their work refer to it as “user errors”.

I was approached by Xander Pollock, Google Ventures Design Sprint facilitator and consultant, to find a solution for this problem. He works with aspiring designers who want to learn how to design for the real world (and get hired in the real world). Discussing the common thread of what his students were saying was the missing gap for them in their preparation to getting hired, the goal for this project was clear.

The Goal |To find a solution that helped designers learn UX/UI patterns terminology and best practices, that was curated and approved by designers who work in the real world.

This was my opportunity to collaborate with Xander and practice the 1-week sprint methodology. His students were our users for the duration of the sprint.


Tools: Post-its, sharpie

Defining the exact problem you are trying to solve helps to make the rest of the sprint go smoothly. By deciding earlier on what problem you want a solution for, there is less risk of getting side-tracked as you come up with solutions.

“Start at the end”

“Starting at the end”, is a mental exercise where you project out 1-month to a year where you see this project ending up. The long-term goal for this project was for the app that would be used by aspiring and seasoned designers alike as the bible for UX/UI terms and best practices.

Using a white board and post-its, the next part of this process was to list all the risk and assumptions that might come in the way of that long-term goal (i.e . “App is not easy to use” or “the list does not stay relevant to designers”).

After that, is the MAP. A little different from a user journey as it is not specific to one user. The map is a tool that allows you to draw out the full experience so that you can later choose one specific target/problem in an experience you would like to tackle first.

Some things observed:

  • Students were familiar with terms, but were not able to naturally refer to them in conversation.
  • Some terms that were more popularly referred to by their shorter name like “navi” or acronyms “api” were referred to by their full name.


The second day’s goal is to find a solution. On Tuesday, we researched existing ideas or ways people have tried to solve this problem by doing what is called Lightning Demos. It is a great way to concurrently conduct a competitive analysis and gather ideas for solutions, as you go through and see what works and hasn’t been working for your problem.

I researched UI courses to see what material they provided, and looked up existing interfaces where UI patterns are taught. These interfaces were found to be both poor vehicles for learning and just too much information. It was hard to see what was something that was a outlier or a term a designer might say everyday. Apple’s developer UI page has since been revamped, but it provided some great examples of how UI patterns could be taught. From this we took the concept of providing multiple examples of the same pattern, which would help broader define some terms.

Gathering a list of this information, I prepared for the next day.


Tools: Whiteboard

We decided we would do UI patterns first, where we would provide a curated list of terms that we ourselves use everyday. The solution we decided on would be a mobile app that brings designers through a full learning process where they would see a UI pattern visually in different forms, and later be tested on what they learned.

On this day, I identified several key features that would be included in our app, for this first phase.

  • List of terms curated by experienced designers.
  • A way to test your knowledge via a quiz.
  • Visual display of your progress.
  • A dictionary of terms you could go back to after you have completed or learned a term, for reference.

This gave a great outline for what I would do on day 4.


“Prototyping is about failing early so you don’t fail late. It’s not about getting it right the first time, or even the second time. It’s about rapidly improving your idea through trial and error, which is a lot less risk than blowing it out fully and then testing it” Jake Knapp in Sprint

Tools: sharpie, paper, Google slides, Sketch

Rapid prototyping is my secret weapon of choice. I already know that the first concepts I have will be iterated upon. So I spend as little time on the details, so I can quickly create a complete experience that I can test. This way I am not wasting time on things that probably won’t make it in the final product.

First iteration for user-testing.

The prototype took users through a flow where they would see a list of terms per category, and when they clicked on that term they would then see different examples of that pattern. Having learned all the terms, they would then take a quiz and see their progress.


Tools: Marvel App, Google Forms, Google Sheets, Google Hangout

For each iteration I did a round of user testing. This is with 4–5 users, which is the optimal number for user testing. Any fewer, you might not be getting enough variety of perspectives, and by the time you reach 4–5 you probably know enough to make some significant iterations to your prototype. When I could, I tried to make small improvements between interviews as well.

For preparation, I created an NDA with Google forms and wrote a script for the interviews. I used Marvel App to help me create a interactive prototype and google hangouts/youtube to record the session.

Things that were affirmed:

  • Users liked that it was mobile-first, so they could potentially use it at any time.
  • The quiz was also something people said was useful.

There was feedback on how some interactions worked and how users saw their progress. Some things that needed improvement:

  • The way progress was displayed during and after learning terms.
  • Rather than the quiz only being available after completing all terms, users wanted to be able to take a quiz at any point of using the ap.
  • The steps on how to see definitions for UI patterns needed to be clearer.

I documented all the feedback using Google sheets, organizing comments by feedback or kudos. This is method that allows you to look at where your product is doing well, and where it needs improvement in a fuller context.

The second iteration was a repeat of Day 5. As I get closer to a final design, I like to put more work into the UI, so that by my final iteration it is near to what I intend the final product to look like.

Second iteration for user-testing.


By the third iteration, my designs clearly met the goals that we set on Monday. I was satisfied with the changes we made based on the feedback these users were able to provide. Although UI Patterns was ultimately not developed as an app, the experience of running with this design problem through the 1-week sprint reaffirmed some things for me.

What I Learned

  • The more time you spend on defining the target problem, the easier the rest of the sprint will be, since there is less risk of getting side-tracked by all the other possible scenarios and solutions you could design.
  • You can do so much in one week! In one week I was able to research, user testing, and create an interactive prototype that could be developed.
  • Rapid prototyping and testing is key to staying accountable to your goals and making sure that what your designing is relevant to your target user. Bringing each iteration before a user is an opportunity to also ask if what you are designing for is actually a problem your users want a solution for.

I look forward to revisiting this app in the future. Having gone through the 1- week sprint methodology many times now, I think it is a practice that can consistently lead to good solutions.