# Pete Randall — Product Designer A plain-text mirror of peterandall.com, including every case study. Each case study is also a standalone page at /articles/; this file collects the full text of the site in one place for crawlers and AI agents. Last updated: 2026-05-29 Canonical site: https://www.peterandall.com/ --- ## About Pete Randall is a product designer. He has spent 15+ years as an IC designer specialising in growing early-stage companies. He enjoys end-to-end ownership, from working out what to build and why, all the way through to shipped features. He is a hands-on builder who uses AI tools to move quickly, thoughtfully and without sacrificing craft. Currently the founding designer at Evidenced (https://evidenced.app), where he has spent over four years building the product, brand, and growth engine. Based in Brighton, UK. Currently available for new work. Contact: - LinkedIn: https://linkedin.com/in/peterandall1 - GitHub: https://github.com/peterandall - Email: pete@peterandall.com --- ## Career timeline - 2007–2010 — Frontend Developer at Preloaded (https://preloaded.com). University placement year followed by a full time role developing sites for brands like GAP, Channel 4 and the BBC. - 2010–2014 — Senior UX Architect at Ostmodern (https://ostmodern.co). Expanded skill set by learning design best practices from industry experts; worked with big brands like ITV, Arsenal and EE. - 2014–2015 — Experience Design Director at R/GA (https://rga.com). Delivered product strategy and execution for brand new digital services for Dyson, Turkcell and Unilever. - 2015–2021 — Founding Designer at Trail App (https://trailapp.com). Shaped the product from pre-seed, enabled 30x revenue growth, resulting in acquisition by The Access Group. - 2021–Now — Founding Designer at Evidenced (https://evidenced.app). Owned all design output through product, sales and marketing; enabled key enterprise deals with companies including E.ON. --- ## Examples of delivering value (homepage cards) - Built Evidenced's design system — Created and owned Evidenced's identity, powering consistent delivery across product, sales and marketing. - Scaled Evidenced's organic growth — Redesigned and built Evidenced's marketing site resulting in 3000% growth in organic traffic and landing a key enterprise customer (E.ON). - Took Trail from idea to acquisition — Helped Trail to find product-market fit, scale the growth engine, weather a pandemic and be acquired. - Shipped Evidenced end-to-end — Worked with the founding team to shape what to build and delivered live features, not just static Figma pages. ## Writing and experiments (homepage cards) - AI workflows — Experimenting with AI 'human in the loop' workflows (Cursor, OpenAI, Claude, Pencil) to speed up product development, brand asset creation and data analysis. - Portfolio site — A walkthrough of how I designed and built this portfolio site, the decisions I made and how I used AI to help me show my work. --- # Case study: Creating the Evidenced design system Over four years I've grown Evidenced's product design system from a Material Design starter kit into a token-driven library. It's defined in code, and powers the features we ship. It also extends to our marketing site, sales decks and event collateral too. ## Where we started When I joined, Evidenced's product UI was Material Design out of the box. The brand had just been refreshed for the move from "Hiring Bar" to "Evidenced", but none of it had been updated in the product yet… Figure: Product UI built from MUI framework, late 2021 ## Setting up the foundations The first thing I did was rationalise the design elements we had. Looking at color, type, spacing and radius, I built a set of tokens that would power the system. These are defined in code, and used to power the product UI. They're also used to power the marketing site and other collateral. We're a small team and it give us all a consistent system to build from. Figure: Colour, type and radius tokens ## Iconography We didn't have the resources to build our own icon library, but knew we wanted to move away from the Android look of the app. So we replaced the MUI icons with the Iconic (https://iconic.app) library. Figure: Excerpt from the Iconic icon library ## Building the components The library of components is the easy bit. The harder, more useful work is agreeing on the patterns that sit above them. Figure: Example Card component from the live system ## Delivering a consistent experience Having a defined system means we can ship features faster and with less rework. It also means we can ship features that are consistent with the rest of the product. As a product team, we're now building features using AI and having a design system means we can have confidence in what the AI is generating. Giving it the necessary guardrails to make sure it's on-brand. Figure: Product screens built on the same system ## Beyond the product The same tokens and components are used in other areas of the business. The marketing site, sales decks and downloads all draw from the same palette, type scale and component vocabulary, so everything we put in front of a customer feels consistent. Figure: Open Graph images built from the same system The polished and considered look helped Evidenced present itself as a premium product, which enabled it to secure multiple rounds of funding over the years. --- # Case study: Rebuilding and optimising the marketing website I redesigned the Evidenced marketing website around the problems our audience was actually searching for, growing organic traffic 3000% and converting one of those readers into a key enterprise customer. ## Defining the problem The Evidenced marketing website in 2022 was pretty thin (like most early startup websites). We had a handful of pages telling visitors what the product did, but nothing helping them understand their own problems. No one was finding us for anything beyond our brand name. Figure: Search Console · evidenced.app · 2022 (baseline: ~6 clicks/day, ~130 impressions/day avg Jan–Dec 2022, 8 indexed pages) ## Building the solution I started by creating a new content plan around the terms our audience were actually searching for, like "structured interviewing". I then rebuilt the site in Framer (https://framer.com) to support the content-first structure. Creating a blog with cross-linking and contextual conversion modules that aimed to surface the right CTA at the right reading depth. I wrote the articles using AI to generate the initial draft and then hand-edited to bring in product specifics without laying it on too thick. Figure: evidenced.app · rebuilt in Framer, 2023 ## Measuring the results Over the course of 18 months, lead-generating clicks went from 6 a day to a peak of 210. Impressions went from 500 to 18,000. One of those readers was at E.ON working on digitising their competency framework. They followed the ideal journey we were aiming for, they read a blog post, self-identified the fit, booked a demo. Figure: Search Console · evidenced.app · 2023 – mid 2024 (growth charts; indexed pages 55 · 2 new every week) Once they'd booked a demo, I handed over to sales but stayed involved. I drove sales enablement and built PDF one-pagers and decks tailored to each conversation. That design work helped close deals. It also surfaced feature gaps in the product, which we added to our roadmap. ## Future-proofing the website The growth strategy paid off, but Google's shift toward AI-generated answers has eroded our SEO traffic — like most marketing sites right now. The next move is optimising for AI engines (AEO / GEO): structured data, explicit factual statements, an llms.txt index, and content that answer engines can quote cleanly. I tested the concepts on this portfolio build and you can see the implementation details in Designing and building this portfolio (https://www.peterandall.com/articles/portfolio-site). --- # Case study: A journey from idea to acquisition My time at Trail exposed me to all aspects of designing, developing and releasing a new product to the world. ## Finding product-market fit I joined Trail just as the product was being proven with some initial customers. It was the early stages of the business and the team were buzzing with ideas and features to build, but we only had one or two customers and not a huge amount of resource. We ran Design Sprints (https://www.gv.com/sprint/) to help us iterate quickly on some key ideas and get early validation. We always tried to build the features that we thought would work for the most customers, but we certainly built things that weren't worth it a year down the line. All of this was helping us find our product market fit. Figure: Sketching at our first Design Sprint More customers meant we couldn't do everything for them. We needed to give them the tools to do things themselves and drive product engagement. The customers who created and managed their own content were much stickier and more valuable to us long term. We also experimented with the team and process, trying to work out the best way to organise ourselves. Pods, tribes, whatever you like to call it, we found multidisciplinary teams working together on distinct problems got the best results. I also created our first design system, to allow the engineering team to build the product in a faster, more consistent way. Figure: Screenshot from our early design system at Trail ## Scaling the growth engine Once we'd achieved product market fit and had a growing customer base, we needed to find new ways to grow. I helped redesign and build our marketing site on Webflow (https://webflow.com). This gave the business the ability to create content, run new campaigns and drive self-service sign-ups. Up to that point, we'd been predominantly direct sales-led. We also spun up a dedicated Growth team to take risks and experiment with new ways of growing outside the business as usual work streams. I led the process and meetings to help prioritise and monitor the different experiments. We used the pirate metrics funnel (https://amplitude.com/blog/pirate-metrics-framework) to identify where best to experiment and which metrics we needed to move at any one time. Figure: Excerpt from the pirate metrics funnel diagram ## Weathering the global pandemic Our growth strategies were paying off, the team were in great shape and we were on track to set ourselves up for acquisition, then COVID hit. Overnight we'd paused pretty much all revenue and app usage, we knew retaining customers long term was much better than trying to find new ones when things got back to normal. We rode out the various waves and lockdowns with a skeleton team. We prioritised features that helped customers stay subscribed and reopen when they could: pausing subscriptions to avoid cancellations, self-service billing, and reopening checklists for the hospitality teams. Figure: Revenue dips during lockdowns in the UK (Revenue · 2015 – 2021) 2021 saw our customers and revenue return thanks to the features we'd built and carefully thought-out reopening campaigns. This led us to acquisition by the leading hospitality software provider in the UK (https://www.theaccessgroup.com/en-gb/about/news/the-access-group-acquires-trail/). --- # Case study: Product ownership and delivery I work end-to-end on Evidenced's product: from sitting with the CEO to shape what to build, prototyping in code, through to shipping live features that customers use. ## Defining strategy with the founding team A lot of my work isn't shipped in a pull request. It happens alongside Phil and the rest of the founding team, deciding which customer signals are worth a roadmap spot, which positioning to lean into, and which deals shape the next quarter. Sitting close to sales calls, support, and customer interviews means I'm comfortable arguing for sequencing, killing scope, or pushing a bet I think we should make. Figure: Example snapshot of our Linear (https://linear.app/) work cycles ## Experimenting and prototyping My career started with making. I picked up a book on HTML and CSS and quickly understood the power of translating an idea into something real. Every role I've had since has followed a similar pattern. Take the research, the conversations, the inspiration, and turn it into something someone can actually use. That's why I prototype in code. A static frame can't surface the friction of a click target, a loading state, or a real dataset. These days, being able to prototype directly in the actual app, against the actual design system, means we can test and evaluate ideas in a more realistic way. Figure: Email reminder sequence prototype ## Closing the loop Working in a small autonomous team means I can often close the loop on my own: taking customer feedback through to shipped feature without costly developer handoffs. I understand the technical constraints before I propose a design solution, and iterate with engineering to make sure the feature works as expected. Figure: Contributions on https://github.com/peterandall · updated daily --- # Writing: Thoughts on AI in product development How I'm using Cursor, Claude, OpenAI and Pencil to speed up product development, brand asset creation and data analysis, with human oversight. ## Using AI responsibly I'm deliberate about where I lean on AI and where I don't. It's most useful for the mechanical work: scaffolding components, capturing screenshots, writing tests, drafting pull request descriptions. It raises the baseline on the hygiene things you should be doing by default, but it's not a substitute for judgement on what to build or how something should feel. Figure: AI automating screenshots and PR descriptions ## AI workflows I've found useful ### Realistic placeholder content AI tools can help mock up real data for UI work really easily. I can stress test a layout and make sure it's working with the actual data that a customer will see. Design tools have had plugins for this for years, but mocking it up directly inside the product saves time. ### Sketching a mock-up, taking a screenshot, going straight into code Depending on the complexity of the feature, I find myself sometimes sketching on paper or in Figma to explore the layout of an idea. Then I'm screenshotting or taking a photo and diving into Cursor or Claude. If I've got a clear idea of how I want the feature to work and what it's trying to achieve, I'm happy to let AI take a first crack. AI gets me maybe 70% of the way there. Then I can refine the feature, either by further prompting or iterations in the browser. Figure: Sketch to code workflow ### Finding insights in user research transcripts, support tickets and sales call notes Usually the more context and the clearer our instructions, the better the results from the AI. That's why for some bets we've been taking, we've been feeding the AI with customer interviews, support tickets and sales conversations to pull patterns, group themes and surface representative quotes. It can help us quickly stress test ideas against a whole knowledge base of insight and feedback and surface things we might've missed otherwise. ### Marketing illustrations from a defined visual style For Evidenced, we use a simple, slightly abstracted illustration style to show different features or concepts from our platform. We use these on the marketing website, presentations and sales decks. I've been experimenting with codifying the design language into a repeatable "Skill" that an AI like Claude can take and consistently create on-brand assets for use in these different scenarios. With the goal being able to share the skill with others in the team so they can create assets themselves. I'd say the output is about 80-90% there and the workflow at the moment still involves taking the SVG asset into Figma to refine the final steps to make it production ready. Figure: Marketing illustrations from a defined visual style ### Identifying accessibility compliance issues I've been using AI to audit accessibility (contrast, alt text, ARIA, focus order) across components and flagging issues for manual review. ### Automated research routines For example, competitive monitoring like a scheduled scrape of competitor pricing/feature pages, then taking a diff against the previous period and pushing an update in Slack of what's changed. This isn't an exhaustive list, it's just a few of the workflows I've found useful. ## Useful resources Keeping up to date with the latest AI developments can feel overwhelming at times, but these are the podcasts I've been listening to regularly to stay informed. - Lenny's Podcast · Lenny Rachitsky (Apple Podcasts embed on the live site) - Platformer · Casey Newton - The Deep View: Conversations --- # Writing: Designing and building this portfolio Exploring how I designed and built this portfolio site, the decisions I made, and how I used AI to help me show my work. ## Exploring the content and story I wanted to give visitors a sense of the ways I've delivered value and the types of work I'm capable of. I used Claude (https://claude.com) to interview me about my time at Evidenced and Trail, and the decisions I've made along the way. This gave me the basis for the content and story of the site, which I then iterated on in a Coda (https://coda.io) document. ## Sketching early ideas I started in Figma (https://figma.com), with low-fidelity sketches to work out the layout and hierarchy of the site. Exploring the IA and whether to use a single page or multi page layout. Settling on a single homepage that links out to a standalone page for each case study. ## Choosing a font and colour palette I picked a fully variable font PP Fragment for the type system, using Glare for display and Sans for body. I wanted something that wasn't a Google Font and didn't feel too much like generic AI output. The palette is deliberately restrained: white on a near-black background, with a single accent colour across links, hover states and the spotlights drifting across the dot-grid background. Figure: Pangram Pangram Fragment ## Iterating in Pencil From the Figma sketches I moved into Pencil (https://pencil.dev) for the higher-fidelity passes. I liked being able to keep my design files bundled in source control alongside the code for the portfolio. Pencil let me iterate on the layouts and case study content faster than I could in Figma, and explore different visual treatments quickly. That file ended up becoming the reference I built the site from in Cursor (https://cursor.com). Figure: Agent iteration using Pencil.dev ## Built with Astro The content is driven by Astro (https://astro.build), which builds the whole thing into a static site. Each case study is written as a plain HTML fragment that Astro compiles at build time into its own standalone page, so every case study is a real, crawlable URL rather than a slice of one big page. Keeping the content as fragments means I can edit the writing directly and let the build assemble the navigation and metadata around it. It also sets up the AEO work later on, since each page stands on its own. ## Animating between pages The site is a simple layout, so I wanted a considered transition between the homepage and each case study, rather than a hard cut from one page to the next. Because every case study is its own page, I leaned on Astro's view transitions to cross-fade between documents: the outgoing page fades out as the incoming one fades in, so navigating still feels like one continuous surface. There's no hand-rolled routing or animation code, and it falls back gracefully for anyone who prefers reduced motion. Figure: View transition cross-fade ## Writing style and tone I wanted to keep the writing short, focused on what I did and the value it delivered. The tools I use show up inline as logos in the moments they were used, rather than as a separate stack page. The case studies themselves stay visually simple, with the prose decorated by logos, icons and colour swatches where it adds impact. ## An ambient dot-grid backdrop The area behind the hero and footer felt a little empty on their own. I added a soft dot pattern with three gentle accent spotlights that move slowly across it. It gives the page enough depth without grabbing attention from the content. The motion stays slow and slightly irregular so it never settles into an obvious repeating loop. The animation is paused when the content is in the background or the visitor prefers reduced motion (like all animations on the site). Figure: Three drifting spotlights ## Optimising for AEO & GEO As I mentioned in the Evidenced marketing site case study, organic search is shifting from blue links to AI answers. Optimising for AI engines (AEO / GEO) matters as much as classic SEO did. Answer engines like Claude (https://claude.com) and ChatGPT (https://openai.com) and the training-time crawlers behind them (GPTBot, ClaudeBot, Google-Extended), have different needs from classic SEO. They lean on structured data, prefer explicit factual statements, most don't execute JavaScript, and look for the emerging /llms.txt convention. Once I was happy with the content for the site, I used Cursor to generate the necessary metadata for the site to be indexed by the AI engines. ## Deploying and measuring I've deployed this site on Vercel (https://vercel.com) as a static site with no build step. It gives me a super simple workflow for deploying and hosting the site, and it's free for personal use. I'm using PostHog (https://posthog.com) for analytics and session replay to give me a clear view of how the site is performing and whether the case studies are getting the traction I want. It's been a fun process putting the site together, being able to push certain AI workflows to the limit to see what it's really capable of. --- # Case study: Evidenced — The interviewing experience A bespoke narrative case study (at /case-studies/evidenced-live-interviewing) on setting the experience direction for Evidenced's structured interview intelligence product, which fills the gap in existing hiring workflows. It tells the story of how I designed and built a key area of the product — the interviewing experience. ## The constraint everything is built around You spend 2–6 hours with a candidate. You can't assess everything. You need to make the best use of that time to ensure you assess the most critical things. This is fundamental to the whole product, not just this feature. ## Existing tools weren't good enough Applicant Tracking Systems (ATSs) do a great job of tracking the candidate life cycle, but they do a poor job of facilitating accurate assessments of candidates. Interviewers and candidates go into a black box and often a hiring decision comes out the other side with scorecards unfilled and no evidence of how a decision was made. ## Where Evidenced comes in Our hypothesis was that by providing interviewers with the tools to collect more data and evidence during the interview, they would be able to make a more informed decision earlier, saving time and reducing bias. Evidenced was built to address that issue, by allowing interviewers to: - Select the right things to assess, the skills and competencies that actually matter for the role. - Assess rigorously, without bias, measuring each candidate against those competencies consistently, anchoring decisions in evidence rather than gut feel. - Prevent losing candidates to a bad experience, a poor interview loses you the people you most want to hire. In the hiring pipeline (Source → CV screen → Interview & assess → Offer, all run on an ATS), Evidenced sits at the Interview & assess stage, breaking it into three steps: 1. Select the skills and competencies to assess against, 2. Interview and capture evidence in real time, 3. Decide with an evidence-based hiring decision. ## The three product pillars Evidenced's value is driven by three key pillars: structured interviews by default, automatic AI-powered evidence collection, and data-driven, accurate decision making. ## Who the experience is for Early on I discovered that interviewer groups interacted with the experience in different ways. Talent acquisition (TAs): high volume, interviewing all day, building muscle memory, time-pressured — the risk is the UI gets in their way. Hiring managers and panel interviewers: low volume, dropped in irregularly, often with no training — the risk is the UI under-supports them. Experienced TAs often want to skip questions because they feel they already have signals and want to reject candidates early. But that is exactly where the bias enters and why the product exists — the structure isn't there just as a guide for the inexperienced, it's there to ensure everyone is assessing the same things consistently. Instead of stripping the interface back for TAs, I kept the original structured interface but gave them more customisation at the template level, so they could build interview packs better suited to their interviews. Admins keep top-level oversight and can lock the key questions every interviewer must ask, with TAs and hiring managers customising around that locked core. If we'd just built what the TA users requested, we'd have a product that was less valuable to the hiring managers and panel interviewers and would have lost the value proposition the product offers. ## Guiding design principle An unstructured hiring process creates gaps where bias and poor judgment can creep in — for example, skipping a question because you think you already know the answer, or being influenced by the first interviewer's opinion. The job of the experience is to close those gaps without making the interviewer feel policed, and without compromising the candidate's experience of talking to a human. This principle is present across the whole product. ## Guide everyone through the interview The interview experience handles three connected phases, each with a different job: pre-interview (coordination — getting the interviewers ready and reassuring the candidate), live interview (guidance — supporting the interviewer and capturing the evidence as a record), and post-interview (recall & judgment — tools to help you quickly review the interview and make a decision). ### Part 1: Pre-interview (coordination) Before the interview starts, the screen is about orientation: familiarising yourself with what you need to ask, who's going to ask it, and then waiting for the candidate. The screen is made up of four main areas: the interview structure in a timeline at the top (sections and time allocated to each), the interview questions and note-taking areas, a side channel for interviewers to talk to each other before the candidate enters, and the candidate in a waiting room who has to be let in deliberately. ### Part 2: Live interview (guidance) During the interview, the UI supports the conversation. The candidate's experience is the highest priority and we don't want to distract or overwhelm the interviewer. That's why I kept the interface minimal. The timeline captures the questions asked, bookmarks, and moments to revisit. Notes attach per question, the countdown flags if you overrun, and the transcript stays hidden by default so it doesn't become a distraction. ### Part 3: Post-interview (recall & judgment) When the interview ends, the interface changes to focus on the post-interview process. The AI extracts the key information against each question and the recording becomes something you can navigate using the main timeline element at the top of the screen. A key decision here was ensuring that other interviewers' notes and decisions stay hidden until you submit your own. This protects independent judgment, and it's a deliberate break from how most ATSs work. ## Designing the interface There was no design-to-engineering handoff on this. I designed the interface in Figma, then built the frontend myself in production on a feature branch. Then I wired it up with the founders, who built the backend and data layer. I like working this way as it collapses the usual gap between the design and the thing that ships, especially on complex features with many moving parts, where I'd rather resolve them in code than defer them to someone else's interpretation. Since the initial release, AI-assisted development has let me move even faster — for anything involving interaction, state, or motion (where a static Figma frame was always an approximation) I now tend to explore directly in the codebase rather than in a design tool. ## Handling commercial complexity The experience had to work for very different customers, from small startups to large enterprises, with different budgets and different appetites for features like AI and interview recording. Some enterprises weren't ready to turn everything on, so I designed the interface in a modular way, with key parts of the experience able to be toggled on and off per customer. That design decision is what made tiered pricing possible: working with the founders, I used it to shape a packaging model that let us close deals with large enterprise accounts who needed to start small. It also gave accounts a path to grow — as customers adopt more features they move up a tier, which has helped turn one-off sales into multi-year contracts. ## Validating the solution Evidenced has a small customer base and is a high-touch B2B product, so I chose research methods suited to small numbers rather than metrics for statistical validation. Dogfooding on our own hiring: we ran our own interviews on the product, which helped us identify issues before releasing it to customers. Session-recording review (FullStory): watching real interviewers showed me where the UI was distracting and where it was working — watching interviewers in action was the only way to observe the real-world behaviour. Structured customer interviews and CS calls: direct qualitative signal from our daily users about pain points and areas for improvement. ## The future of the interviewing experience The explosion in AI usage has had a significant impact on structured interviewing. On one side, candidates using AI during live interviews can reduce the effectiveness of the assessment — if you can't tell whose thinking you're evaluating, the evidence is worth less. That pushes the product towards assessment built on real work and real scenarios, which is harder to fake. On the other, AI is now part of how people actually work, so assessing how well someone uses it has become a skill in its own right, and that's where I'd be investing. --- ## Testimonials > Pete's curiosity and rigour has brought so much value to the team. He's always looking for gaps and ways to improve things. He executes quickly and precisely and is always pushing to make sure we ship the most impactful changes to our product. > > He's embraced AI and is keen to find ways to bring it into the organisation to improve our processes. He's a great hire for any team that values autonomy and getting things done! > > — Philip Spain, Founder & CEO, Evidenced (https://evidenced.app) > Pete has such a great skillset for startups, he can design, build, and ship. He worked closely with me and the founding team to shape the product (and business direction) throughout our journey. > > He cares deeply about the things he creates and has a really strong attention to detail. Pete would make a valuable addition to any team and someone I'd definitely work with again. > > — Wil Grace, Founder & Product Director, Trail App (https://trailapp.com)