Adam James Huston

UX Designer

product design, project management, UX consulting


I am a UX Designer and Associate Facilitator at Kenzie Academy. In addition to managing a classroom and mentoring the next generation of designers and engineers, I take ownership of feedback processes and systems, student outcomes, and continuous program improvement.

I studied fine art at Ball State University from 2006 to 2011, which honed my observational skills and design thinking.


wearing a lot of hats gives you superpowers

Once a freelancer, bike messenger, and barista, now I’m a designer, startup whiz, and process dork.

That's how I describe myself on LinkedIn. Privately, I think of myself as an adventurer. I’m resourceful, I like to explore new territory, and I’m passionate about changing the world. In my adventures I’ve had the pleasure of seeing the world from many vantage points: I’ve served local services, non-profits, scaling startups, startups at scale, retail, publishing, enterprise SaaS, and more.

My terrain experience makes me a skilled organizational guide and diplomat. I identify problems, design and build scalable solutions, build visibility with systems, onboard talent, and grow cooperative organizations.

I also like On The Media, Murray Bookchin, Assassin's Creed, Overwatch, underground rap, bikes, bieks, b i k e s, and coffee.

Design Thinking

Want to be a UX Designer?

Well, the hard way to do it is to go to art school for painting.

Not because painting will get you a job, but because when it doesn’t, you’ll have all of the experience, brainpower, and soft skills you need to make it in tech!

Ideation? Been there. Iteration? Done that. Bruising critiques and complex interpersonal dynamics? Old news. You might call me “battle-tested”. “Seasoned” might be premature, but who isn’t a little salty these days.

A shortened list of professions I've held since art school: a groundskeeper at a graveyard, a barista, a bike messenger, a call center employee, a product photographer. I eventually began freelancing as a designer - designing posters, brands and websites.

What does it all have in common? In all of these roles I exercised the grit, creativity, and problem-solving I developed in the studio. When art critics are describing a painter's need to create new paintings, to strive towards a greater and greater masterpiece - they're referring to what the tech industry calls "design thinking".

The creation of an artwork is, at its core, product design: it's cyclical, it has multiple inputs, it's sensitive to the needs of its audience, and it's constantly re-inventing itself.


A focused portfolio showcasing design thinking, product design, and UX techniques.


app concept: a peer-to-peer services platform for property owners and lawncare services


Inspired by my buddy Dave, mow is an idea for an app that would make his life easier. Dave does odd jobs and specializes in landscaping. Odd jobs can be both physically and emotionally challenging: he often has to manage difficult customers and demanding bosses.

Dave would like to be his own boss without needing to worry about finding good customers. A peer-to-peer services app could offer a solution.

Specific Challenges

The app design and business model must define and negotiate user requirements for two different groups of end-users: lawn care customers and lawn care providers. Interfaces must seek to maximize participation.


Make shopping, scheduling, and budgeting for lawn care easy. Make working for good money hassle-free. Interface must be forgiving and the experience should encourage repeat business.

Explore and define


To make sure my designs would fit the needs of both user groups, I constructed two surveys - one for customers, and one for service providers. For the uninitiated: User personas are compact summaries of user archetypes designed to illustrate user behaviors and priorities. Meant to be good reference material, personas are valuable tools that can be referenced throughout the product’s life cycle. The better informed your personas are, the better your resource.

Five property owners responded to the customer survey, and three service providers (Dave was one of them, said the magician who shows his tricks). I supplemented these responses with demographics data for homeownership and the gig economy, which gave me some confidence.

Application Maps

After constructing user personas, I created a required minimum feature list for both groups. These lists helped me determine that there would need to be separate environments for both kinds of users, in order to manage both sets of needs.


  • Create a profile
  • Search for and order services
  • Pay for services
  • Reschedule/cancel services
  • Track and budget service purchases
  • View calendar / appointment reminders


  • Create a profile
  • View/Accept/Decline jobs
  • Get paid
  • Track pay
  • View calendar / appointment reminders

I then mapped both apps, identifying screens and interaction flows. Application mapping creates a flexible task list throughout design and development. These illustrations grant visibility to the final product early on, help us anticipate complications, and prevent rework. They can also be expanded upon as new ideas emerge. Here are the first iterations of my maps for this project.


Following the maps above, I created wireframes to define the individual screens and ensure all user requirements were met.

Good wireframes get great mileage. Not only do they encounter and resolve details not addressed in the app map, they also guide the next phases in several ways: firstly, they act as templates for high-fidelity mockups, which themselves become precise patterns for UI developers to follow. Secondly, they can be used to make additional resources, like interactive prototypes (for customers and providers) and wireflows. Taking on additional design phases create opportunities for testing, editing, and feedback. By approaching these designs from multiple angles I can make sure we account for and address as many unforeseen problems as possible.

Next Steps

Visual Design

Often, UX Designers inform and take ownership of the visual design of the brand and the app. With my user research and wireframes in hand, I felt well-equipped to make some suggestions.

Finally, I can begin making a components library and high-fidelity mockups. But that’s for another day! I’ll need to test these prototypes, first.


Before doing more visual design, I’ll devise some observational studies. Usability testing should uncover aspects of the app design that are confusing, lacking, or otherwise underbuilt, and reveal more suggestions for visual design.

Testing could also reveal major flaws that might make this product as a whole untenable, which isn’t all that unfortunate. In that case, I will have saved my stakeholders money and my developers years of their lives by recommending that we don’t develop a bad product to launch. UX at its finest.


Managing relationships between two user groups with distinct but complementary needs is a complex task, but achievable if you start with the right methods and the right experts.

In order for apps like these to succeed for their users, software companies must not only be able to understand how they live and interact with their product, they also need to be able to design and develop efficiently. Projects like these demonstrate how UX Design accomplishes both.


app concept: pet healthcare organizer


The life of a freelancer can be very liberating! You can choose your own hours, you can pick up new skills, you can take on challenging jobs to expand your skill set. However, it comes with costs, too: collaboration can be difficult and disconnected, projects are usually short-term, and systemic impact can feel way out of reach. I was feeling the pinch - I had big dreams! So, in the Fall of 2018, I went back to school. Not just any school: Kenzie Academy.

Kenzie Academy’s UX Design curriculum promised an immersive, startup-like experience learning from designers from Google and LinkedIn. Say no more, fam, say no more. The first project: design a mobile application from concept to hi-fidelity, utilizing UX methodologies and the fundamentals of UI Design.


Utilize UX research methodologies to discover and design an app that will meet the needs of pet owners. Use iterative design processes to realize intuitive user interactions. Practice UI Design principles and consistency across a relatively large feature scope.


Work in groups of two to deliver a feature-rich high-fidelity prototype that addresses the diverse needs of pet owners.

Explore and define

Problem Space

Background Research

Tech industry tried and true - my partner and I turned to Google for a starting point, and dug up some interesting context:

  • Over two-thirds of all U.S. Households own at least one pet- that is roughly 85 million homes. (Springer 2018)
  • Pet owners care most about level of care followed by cost and location.
  • The most common reasons for veterinary visits are difficult or impossible to diagnose at home (Thrift 2014)

Competitive Analysis

In order to solve the problem, we would first have to get more specific about what, exactly, “the problem” is! We started by looking at what apps already exist, and why pet owners may or may not be using them.

Key Takeaways

  • One competitor is not an app; no competitors are platform neutral
  • A few are all-in-one solutions; some may be too detailed
  • Most feature the ability to search for vets and care services; very few feature the ability to search for general information on symptoms and conditions
  • None of these apps are very popular, some are unpopular

User Discovery

We asked pet owners to fill out a screener survey, giving us a pool of users to interview and model. The screener survey itself had some insights:

For the interviews themselves, video calls came in handy for getting a lot of information very quickly.

We learned that the majority of pet owners have only 1-2 animals (that they care deeply about), but owners with 3+ pets are a significant user group.

Interviewees and survey respondents stated convenience, dependability (and accuracy), and fast access to reliable information were their highest priorities.

Problem Statement

From here we worked on a few brainstorms.

This whiteboard is a general mindstorm, imagining the kinds of features and relationships that exist in our users’ dream app. Based on our interviews, we imagined that this app would be an all-in-one solution that lay at the intersection of three problems:

  • Users have to check a variety of tools to get complete control and information regarding their pet’s [healthcare] needs
  • Many information sources about pet health online lack credibility and reliability
  • Costs [at vets] aren’t transparent

From this we derived our product’s problem statement:

“How might we unify and streamline the tools pet owners use to care for their pets?”

But before we get ahead of ourselves, let’s make sure we identify our assumptions:

Listing assumptions is a good way to poke holes in the viability of the app, and look for innovative solutions. Some of these assumptions should be challenged. Some are safe: we’re building an imaginary app, after all.


Why a storyboard?

A “user experience” is a story. It’s anecdotal - it has a setting, characters, problems, and resolutions. Imagining our user experiences in this way brings vibrance and empathy to our work, giving designers (and stakeholders) a concrete and memorable narrative to center on.


Similarly, we can create illustrations of our users, bringing the characters in these stories to life.

Content Mapping

User Flow

How to manage the task of creating an all-in-one app?

We started by trying to model everything our users might want to do, with as few features and interactions as possible.

This gave us a decent starting point not only for our first wireframes, but our information architecture.


An information architecture diagram tries to capture the hierarchy of the content in the app. From the user flow, we tried to extrapolate a basic hub and spoke diagram.

We tested Diagram 1 with a card sort, which gave us Diagram 2.



Back to the drawing board for some navigation options.


Progressively more detailed iterations continue to refine interactions, helping us discover what will and won’t work.

Even though we challenged ourselves to make an “all-in-one” solution, features like the cost estimator wouldn’t make it to the final design; taking the time to imagine as many possibilities as possible in these early phases helped us define a realistic MVP.

Prototyping and Testing

Personally, I like to compare iterating and prototyping to rocket science: when rockets blow up on the launchpad, rocket scientists look at each other and say “this is why we test.”


Design System

The interesting thing about design, to me, is that design thinking is fractal. You have processes within processes, and all of the work you do informs all of the rest of the work you do. The trick, then, seems to be identifying avenues that won’t be fruitful early on. For example: we have a lot of different kinds of forms and text inputs in our app. In order for these functions to be usable - in order for our users to look at these screens and know what the heck was going on! - we’d have to use conventions our users would be familiar with. You don’t want to have to redesign the concept of form fields, before building a bunch of forms.

Adopting components from Material allowed us to focus on something more fun: Color.

Hi-fidelity Iterations

Of course, all of that crashed and burned, but the design thinking process proves out: imagining what’s possible allows us to experiment and understand - in concrete, objective ways - what will and won’t work. Just as Material gave us solutions for our form visuals, we would also be able to source Material for our color usage.

Final Screens

Solutions don't come easily. It would take several more iterations to hammer out specifics like: what color should the banners be? How many different button styles are we using, and can we use fewer? Are our active and inactive states consistent?

With each iteration we'd update our prototype, until we had a version we felt demonstrated all of our key features, a clean, consistent UI, and an intuitive user experience.

See for yourself!

Next Steps

An interesting thing about this process was learning how to prioritize design work. Determining how much of the design to detail - how far to drill down in order to address our app's requirements - would play a key role. We were able to stay consistently high level in terms of our visuals and our user experience, without getting lost in the weeds.

That said, there's no stage in which a product is ever finished: there's no point in which a product is 100% perfect, as business needs and user needs change. Even though this product would never see development, it's good practice to continually recognize what tasks still could be done.

Here's what's on our list:

  • Finish and test search flow
  • Finish and test interactions for adding and managing multiple pets
  • Write screenreading guidelines
  • Motion throughout

Meal Plan

design sprint: from problem to proposal in six hours


A common misperception of UX research is that it’s costly and time-consuming. There are two ways to push back against that: you can appeal to common sense, and point out that exploring a lot of different directions before committing to dev time is virtually cost-less and preferable to winging it and building the wrong thing.

Or, you can flex and spend the day designing a credible product from scratch.


The prompt: "Design an app that enables customers to split a check at a restaurant."

The constraint: Sometimes you only have a day or two to come up with a good idea. And, it's nice to show your boss something cool by the end of the day, so I gave myself six hours.


Design Thinking has 5 phases that each fuel each other: Empathize, Define, Ideate, Prototype, and Test. In order to make a credible proposal in six hours or less, I translated these phases into time blocks and identified action items for each:

  1. Context (10a — 11a)
    • Problem Statement
    • List Constaints/Assumptions
    • How Might We’s
  2. Users (11a — 12p)
    • Problem Statement
    • List Constaints/Assumptions
    • How Might We’s
  3. Break for lunch!

  4. Setting the Stage (1p — 2p)
    • List Requirements
    • Brainstorm Solutions
  5. Design (2p — 4p)
    • Wireframes
    • Feedback
    • Iterate on Feedback
  6. Final Considerations (4p — 5p)
    • Edge Cases
    • Next Steps
    • Last Thoughts

Plan in hand, I went to work.


Planning happened over breakfast, and my schedule started at 10am. So, I made a pot of coffee and worked in my dining nook for the most relaxing sprint possible.


Most of the work for this project took the form of organized note-taking. I'd begin by outlining the Problem Statement, the Constraints, and the Assumptions.

Problem Statement

Design an app that enables customers to split a check at a restaurant.

Using the prompt here helps keep the solution focused and relevant.


Split check AT restaurant (can be spontaneous)

Customers do it (not the restaurant)

Due by end of day (solution should be succinct and easy to explain)


This is a common frustration (Haven't people mostly figured out how to handle the task of "bill splitting" relationally or through existing tools? Is their frustration that they don't have a good bill-splitting tool, or is it something else?)

Existing solutions are inadequate (Why take six hours to re-invent the wheel, if users already have wheels and instead want to fly?)

One interaction with the restaurant per group seems ideal (implied by "bill-splitting" - is the need for "bill-splitting" a user-driven pain point? Is it possible the desire for bill-splitting solutions is stronger from restaurants seeking more efficient transactions? Do users desire fairness and ease of making a transaction? What are their actual desires?)

It should work at every restaurant (does it have to?)

The Problem Statement serves as a guiding standard - whatever I come up with should solve the problem stated. Constraints are limits, and assumptions illustrate what beliefs exist that might need to be challenged.

First Brainstorm

I could already see in my first three notes that a lot of my questions had to do with the problem statement - the concept of "bill-splitting" itself was starting to show inadequacies. In order to set the context properly, I decided to brainstorm more useful problem statements. I started by restating the prompt's constraints.

Orange: Problem Constraints

According to the given, there must be an app that enables customers to split the check at a restaurant.

Pink: Pain Points

I imagined some common problems people have related to payment while eating out at restaurants in groups.

Green: How Might We? Questions

HMW make splitting the bill pain free? (get ya later)

HMW incorporate multiple forms of payment into a single transaction?

HMW change the time a payment needs to be made?

HMW make group ordering fun and easy?

HMW encourage eating out in groups?

HMW find lunch buddies?

HMW eat good food every day, even when we're broke?

HMW design a unique dining experience around group membership?

Understanding the User

From my HMWs, I was starting to imagine solutions. But before I get there, I should talk to some users, first.

I'd keep my interviews short to encourage engagement keep the focus tight. The goal is to uncover their pain points without leading them to a solution.

Guerilla User Research

Interview Script

Q. Do you eat out in groups, ever? Why or why not?

Q. What's the most awkward part of eating out together?

Q. How do you usually split the bill? what's the worst thing that can happen?

Q. What would your ideal solution be?

Delivery: I forced some friends in my network to answer these questions via Slack and iMessage.


Interviewees all express enjoyment at eating out, and frustration at the social pain points and cost.

Interviewees are not without solutions to the problem of splitting the bill - they're seeking technological solutions to cost and social awkwardness.

Interviews envision a wide variety of ideal solutions and weren't in agreement as to how to resolve this, however one interviewee joked about a communal lifestyle where paying for food wouldn't be necessary

Interview Responses

I also surveyed the landscape to see what software solutions already existed.

Competitive Review


Splitwise keeps a running total of who owes who what—from the last three grocery runs you made to the Friday happy hour that your roommate sprung for. When you’re ready to pay up, a simple PayPal transfer is all it takes to settle your debts.

Billr will calculate what everyone owes for their own entrées and split shared items. The app will also add in the tax and tip and even send a copy of the split bill to the rest of the group as a text or email.

Divvy: snap a picture of your receipt, drag each item to the person who’ll be paying for it. The app will automatically add the appropriate tax and tip to each person’s portion.

Venmo: Remind your friends who owes what with this free app that lets you send money requests at any time. You can also pay your friends back if they request you.


Lots of bill-splitting and money-sharing apps exist.

Most of these apps focus on the organization and sharing of money, fairness, and so on. Some of them even have the ability to keep a running tab with a friend, such that you are each other's bankers.

None of the most popular apps named focus exclusively on the experience of eating out together at a restaurant.

See what happened, there?

"Bill-splitting" isn't the real problem! People have all kinds of ways to make transactions fair. The real problem is more direct: budget constraints cramp otherwise valuable social dining experiences. People like to (and feel pressure to) socialize in order to keep up with their peers, but keeping track of spending causes distraction, avoidance, and anxiety.

At this point it's barely noon. What a nice morning! I turned all of my screens off for a quiet lunch, then came back for...

Setting the Stage

Having defined the problem, it's time to imagine some solutions.

I'll start by adding some new constraints, based on the previous research phase. Specifically, now that I know more about my users, I can list what they require in a solution, and what they don't require. I'll use this list to evaluate any ideas I come up with.


Solution should encourage the positive aspects of eating out: good food, frequent socializing

Solution should accommodate people with hearing loss and other accessibility concerns

Solution should focus on relieving the social pain points - other apps and existing technology provide adequate coverage for handling money and making payments

Negative Requirement

Users don't express a desire to be betetr organized. Instead, they are expressing a desire to be in control of their "pain" in the moment - how much they pay, and for what.

Armed with a list, now I can brainstorm. I focused on ways to separate the payment experience from the social experience of dining at a restaurant.

Table Tablets

A "connected" restaurant places devices for delivering bills and taking payments at each table

Pros: Makes for a fun, accessible dining experience, and smooth communication with Kitchen 

Cons: Only works at that restaurant

Pile It Up

Members of an eating group contribute to a "pot", and pay for bills from the pot

Pros: one transaction to the restaurant, pre-arranged agreement

Cons: everyone has to has to have the app, can't be spontaneous, fairness concerns

Front Me

Similar to a credit card, Front Me will pay for transactions "Up Front" and requires the user to repay within a timeframe 

Unlike a credit card, Front Me has a monthly subscription fee instead of interest, and only works at restaurants

Pros: Circumvents multiple checks and some members of the group not being able to pay for their own food, without adding an additional tool to the "how do I pay my friends back" toolkit

Cons: what if everyone stiffs Front Me

Meal Plan

Similar to Front Me, users subscribe to a meal plan that covers x meals/week

Pros: Take paying for things in the moment out of the moment, relieving pain. It's paid for! You have a meal plan!

Cons: Likely an upper limit (to stay within a feasible business model), so this is only pain relief, and not a pain cure, when it comes to paying for large groups.

Of these ideas, Meal Plan seemed to do the best job of removing both removing the pain point and encouraging situations people desire, so I fleshed it out a little more.

Company Meal Plan

A B2B SaaS provider that works with employers in metro areas to provide free lunches at restaurants to its employees as a benefit.

Meal plan comes with 1 "treat" meal per week that can be used with someone outside of the company or on the weekend.

This description is enough to model the interaction as a user flow.

Nice and simple!


On to the next phase! At this point these sprints are feeling downright relaxing. I have coffee, I have my cat, I have chirpy birds outside, and I have a great idea! The best part is,

My secret is pen and paper. Whiteboards are even better, but I didn't have access to one.

Show the drawings to some friends...

"What is this? A lunch card?"

"Emulating a physical punchcard is cool, but this wheel arrangement is too arty."

Nailed it. Let's go to screen.

I'm starting to run out of friends to ask, so I turned to begging people on Slack. It's not repetitive, it's cyclical. Some of those notes:

"Why is the thumbprint visible in all of these?"

"Oh, cool - pay with Apple watch! That'd be insanely easy. Now, if only i had an Apple watch."

"How do I load it?"

You don't need a lot of social capital to be a product designer, but it doesn't hurt!

So what's left?

Oh, yeah, let's try it for Apple Watch.

Final Considerations

Constructing conclusions is a phase unto itself. And, why not? It's only four o'clock. As a designer, reflection ensures completed work is in alignment with the greater vision for a project, uncovers areas of opportunity for further design, and creates space for more creativity.

Edge Cases

In the smartphone iteration:

Maybe the service decides it's necessary that users can only use 1 regular punch per day, so after that punch is used unused punches turn into a pie-graph timer to illustrate when the freeze-out expires and punches are available again.


Further resesarch required: how do users without fingerprints use features like apple pay?

Next Steps
  • User-testing: are there any features missing? What data would they want to see?
  • Feature validation: is this product engaging, to employees and employers, for the reasons we expect it will be?
  • ROI/expense research: Can this be made not only affordable to client companies, but profitable to us?
  • Client interviews: How much would a company be willing to pay for this service? What value would this service provide them? What aspects of the business model would be most important to them? Any dealbreakers?
  • IT: what are the logistics of using chip payment methods between smartphones, bank accounts they don't own, and restaurants?
Last Thoughts

While the prompt was to create a bill-splitting app, user research and competitive analysis revealed that splitting the bill is a solution in search of a problem. The actual pain points of going out to eat in groups are more about social interaction: who will pay for what, what to do when someone can't pay, how to navigate money issues without hurting anyone's feelings (or wallets) and still be a member of the group. The actual joy of going out to eat isn't splitting the bill, it's having good food and spending time with people.

An app like this one would (hopefully) empower employers to provide an additional benefit to employees by offloading some of the pain of eating out, encouraging employees to take meals together and invite people from outside the company to join them, guilt and awkwardness-free.

And... that's it! Problem to proposal in six hours. The secrets to success?

  • Make a complete plan.
  • Use pen and paper or whiteboard.
  • Use Design Thinking cycles to generate ideas and iterate on them.
  • Find and listen to your users.


Coming soon.