← Work / UX Case Study

Flock: designing a product people could actually use.

A full UX process — surveys, sketches, wireframes, testing, and final UI — with the dead ends left in, because that's where the good decisions came from.

Role
UX research & UI design
Timeline
[X weeks/months]
Tools
Figma, user surveys, usability testing
Type
[Client / self-initiated]
Hero image — final Figma screens in device mockups
(drop in: img/flock/hero-screens.png)
The finished product first — then how we got here.

TL;DR

The short version: Flock is [what Flock is, in one plain phrase]. I owned the process from research through final UI — surveying [X] people, sketching and cutting a pile of ideas, and testing wireframes with real users. Testing changed the design in [X] meaningful ways, and the final screens reflect what users actually did, not what I assumed they'd do.

The problem

What's broken, and for whom.

[The user problem in one sentence a non-designer would nod at — e.g. "People who want to do X end up doing Y, because every existing tool makes them Z."]

The people feeling this most: [who your users are and how you scoped them]. This was a [client project / self-initiated study], which meant [what that meant for scope and freedom].

Framing visual — the painful "before" experience, or a simple problem-statement card
(drop in: img/flock/problem-framing.png)
The starting point: what the experience looked like before Flock.

Constraints

The real-world stuff.

Research is never as clean as the textbook version. Here's what was scrappy about mine:

  • Timeline: [how long you actually had, and where it pinched]
  • Recruiting: [who you could realistically reach for surveys/testing, and the limits of that sample]
  • Scope: [what you deliberately cut to keep the project shippable]

Owning these up front matters: every decision below was made inside these limits, not in a vacuum.

Research

Asking before assuming.

I started with user surveys — [X] respondents, recruited via [where/how] — asking about [the behaviors and pain points you probed].

What I expected to hear: [your going-in assumption].
What I actually heard: [the finding that surprised you].

[X%]
[Key survey finding #1 — e.g. "said they abandon the task entirely when..."]
[X%]
[Key survey finding #2]
[X]
[Key survey finding #3 — could be a count, not a percentage]

"[The one survey response or insight that changed the direction of the whole project]"

The aha moment

Research artifacts — affinity mapping, raw notes, or survey analysis in progress
(drop in: img/flock/research-synthesis.png)
The mess becoming structure: synthesizing survey responses into themes.

Ideation

Lots of ideas. Most of them wrong.

The research pointed at a few "how might we" questions: [your 1–2 HMW statements]. From there I sketched wide — paper wireframes, quick variations, ideas I knew were probably bad but needed to see anyway.

What got cut early: [one specific idea you killed and why — e.g. "a feed-style layout, because the research showed users wanted to finish a task, not browse"]. Killing it stung a little. It was also obviously right.

Sketch grid — paper wireframes, crazy 8s, whiteboard photos. Keep it messy; the mess is the point.
(drop in: img/flock/sketches.png)
Early explorations. The winning direction is in here somewhere — so are six losers.

Testing

Where users proved me wrong.

I built wireframes for the core flow and tested them with [X] people — [moderated/unmoderated], working through [the key tasks you set].

Where they got stuck: [the specific stumbling point — what users did vs. what you expected]. That stumble revealed something I'd completely missed: [the insight].

The honest pivot: [the thing you were attached to that testing made you redesign].

Before testing
Wireframe v1 — the version users struggled with
(drop in: img/flock/wireframe-before.png)
[What users did here that you didn't expect]
After testing
Wireframe v2 — redesigned based on what testing showed
(drop in: img/flock/wireframe-after.png)
[What changed, and what happened when you re-tested]

From wireframe to UI

Every decision has a receipt.

Moving into high-fidelity UI, the visual direction needed to [the feeling/job the UI had to do for these specific users]. Here are three calls I made and where each one came from:

01

[Decision #1 — e.g. the navigation pattern]

Because: [the survey finding or test result that drove it — "Users in testing did X, so I did Y."]

02

[Decision #2 — e.g. the onboarding step]

Because: [the evidence behind it]

03

[Decision #3 — e.g. a layout or content choice]

Because: [the evidence behind it]

The result

The final screens.

One core journey, start to finish: [walk the flow in a line or two, as a user would experience it].

Final Figma screens — one key flow, 3–5 screens, generously sized
(drop in: img/flock/final-flow.png)
The core flow, refined through testing.
Final screen detail #1
(drop in: img/flock/final-detail-1.png)
Final screen detail #2
(drop in: img/flock/final-detail-2.png)

Outcomes

What it showed, and what's next.

  • Validation: [what final testing showed — improved task success, clearer comprehension, positive signal]
  • What changed in me: [how this project changed your approach to research going forward]
  • Still open: [the question you'd test next — products are never done, and that's the point]

If this project got another sprint, I'd start with [your #1 next step] — because the research raised it and the timeline didn't allow it. That's not unfinished business; that's a roadmap.

Like how this came together? Let's talk.

I bring this same process — research, honest iteration, decisions with receipts — to every project.

Send me an email