Welcome to Researched.Design

Hello and welcome! I’m Jesse Klotz, and this is my portfolio for UX Research & Design. I’m excited to share the approach I’ve developed throughout my career — one that blends research and design to create exceptional user experiences. As a UX Researcher and Designer, I dig deep into user insights through interviews, surveys, and usability testing, uncovering valuable findings that guide the design process. With a focus on user-centered design, I craft interfaces that are both visually engaging and highly functional.

In this portfolio, you’ll find examples of how I integrate research and design to deliver meaningful, impactful solutions. Take a look around and see how I can help solve your unique challenges through thoughtful, user-focused design.

Enjoy the experience

Design
Process

Idea

Brainstorming and defining how a product should work and who it is for sets a foundation for the entire project

Vet

Verifying with users and potential users that the idea will effectively impact the consumer

Produce

From wireframes to full resolution prototypes, ensuring the ideas are passed from design to engineering as concise as possible

Nurture

Recurrent testing, market research, and updates are essential to the survivability of the product

Brainstorming
Engineers, product, design, & research come together to discover and verify the needs, features, and new ideas of the personas
  • During brainstorming sessions, no ideas are bad ideas. Often the best ideas are generated when mental barriers are removed.
  • Let the conversation meander. The more conversation a group has, the better.
  • When struggling to formulate solutions to an issue, try to create the worst solution to solve the problem.
  • During brainstorming, whiteboards, post-its, pencils, and paper are your best tools. They are easy to get idea out quickly and efficiently.
STORY BOARD ING
Creating a mental model of the application before pushing around pixels will give you a great start.
  • The architecture can be put together and re-ordered quickly
  • Easier to include others with little to no design ability
Wireframes

Point #1

Wireframes are produced in grayscale, to accentuate the core elements.

Point #2

Elements that are not a focus of the wireframe are generally left as blocks (e.g. the shell of an application would be represented by a bar or block)

Point #3

A wireframe to the final design is analogous with rebar in concrete; you wouldn’t know it’s there unless you were part of the construction.

Static Wireframes

  • Clicking through a series of pictures to understand how an application or website will flow
  • Invision, Figma, Adobe XD are most commonly used for building static wireframes
  • These types of prototypes are great for quick turnaround and feedback on a project
Example here

Working Wireframes

  • Working prototypes are generally built like a normal website using HTML, CSS, JS, and a little PHP if necessary.
  • When an application is complex and a specific flow needs to be verified, it may be easier to get a response with a working prototype.
  • The Desking prototype is an example of a working wireframe that helped us identify pain points during user testing
Example here
“If a picture is worth 1000 words,
a prototype is worth 1000 meetings.”
-Tom & David Kelley

High Resolution Deliverables

Final Hi Resolution Mockups

Mockups

Final deliverable on how a software or website is supposed to look

Final Hi Resolution Prototype

Prototypes

Final deliverable on how a software or webite is supposed to feel

Analytics as a type of data

Data

Hindsight is always 20/20. Record data to adjust for the next project or iteration

Quantitative Analytics

Quantitative gives you a direction to steer the ship and confirm the course with qualitative research

Analytics

  • Majority of analytics types would be classified as quantitative. Session recordings, depending on how they are used, could be the outlier.
  • Analytics can help you see where customers are entering your site, getting traction, dropping off, and so much more.
  • Having funnels and goals implemented on the site or application make tracking and recording easier to manage.
  • Quantitative data can help you determine if a user group is using your site as intended. Just because a user can follow a script in user testing, doesn’t mean that is how the general public will use the application.

Surveys

  • Surveys can help figure out priority within the product department by weighing specific elements of the website or software.
  • One of the most difficult things about surveys is determining the phrasing of questions that does not lead the user to a specific answer or idea.
  • Surveys can also run double duty by testing new UI elements before they make their way to production.

Qualitative Analytics

Qualitative research confirms the quantitative research you’ve done and opens the door for things that aren’t able to be gauged by quantitative. You learn first hand frustrations that cannot always be recognized through quantitative research.

User Testing

  • User testing, generally, is best completed one-on-one or two-on-one, with the session being called into a watch room and/or being recorded
  • I’ve had the pleasure of talking to clients of the product, in either good or poor standings. They have more vested in the future and process of the application because they use it every day.
  • I have found to learn most about the software from user testing: either by watching the user or asking questions

Focus Groups

  • A group of individuals to go over a topic, product, or feature of a product
  • The focus groups that I’ve been apart of have mainly been for the infancy of a product to ensure we cover all aspects.
User testing session at a car dealership
This is a talking example of how and why I organize my testing documentation.
TLDR
  • The most important items should be summarized here
  • Easy wins and bigger discoveries need to be highlighted here
  • This is the only section that gets read by a majority of stakeholders
Who
  • Who was tested
  • Any information about them should be recorded here
Notes
  • Any and all notes you are able to take during the testing
  • Can either integrate multiple sets of notes or keep separate
Items Tested
  • All material that was covered should go in this section
  • Should have a snapshot what was tested
  • Wireframes, mockups, prototypes, zipped websites/applications
Recordings
  • If your documentation server can hold these files keep them private
  • Keeping them unlisted on Youtube or another video host is also a viable option
But Why Document?
  • Referencing previous testing sessions can help with future design decisions
  • Ability to share the data (regardless of how much it actually gets read)

A little about me

Hello again! Glad you made it through. I'm currently a Senior Designer with West Monroe Partners. I was previously a Senior UX Researcher and Designer at DealerSocket, an automotive software company. We had a fairly small design team so you have to be a jack of all trades. I have done everything on the research and design spectrum from gathering analytics to handing over final high-fidelity designs. Some of the larger projects have been turned into portfolio pieces you can dig through on this website.

My career started as a front-end developer at DealerFire creating and developing custom automotive dealer websites. After a couple years as a front-end developer I earned a role in engineering. I was the lone person creating, perfecting, and maintaining OEM templates for my former department to use. The understanding I have for how the applications and websites are created and run benefits design choices that are made. It also helps with creating real-time prototypes when necessary as you can see in the Desking example.

My motivation is fueled by learning and creating new things: from woodworking to photography to coding to anything in between. I really enjoy coaching and creating a similar experience for others. For track and field, it makes my season when an athlete gets the eureka effect.