![Dealfront AI inside the Company Profile](https://www.twine.net/signin

Dealfront is a B2B go-to-market platform. Its Company Profile already held everything a salesperson needed. The problem was reading it. Visit logs ran hundreds of lines. Contact tables listed every employee with no way to spot the right one. Research meant opening other tabs, and the findings never came back into the product.

I designed an AI layer that answers the questions people were already answering by hand.

What I did

• Turned real questions into one-click cards. I ran the interviews, then built the questions salespeople actually ask into the interface, with a free text field for everything else.
• Killed my own first design. Round one was a single “Generate summary” button. Testing showed the summary was fine, but it was never what people would have asked for. Control beat automation.
• Connected answers back to the table. Instead of a tooltip marking recommended contacts, a toggle filters the table down to just those people.
• Let people pin questions. A good prompt becomes a reusable card. Nine show in a grid, the rest sit behind “Show all”.
• Named the sources. External claims link to the news item or filing. When the source is our own data, the interface says so.
• Gave AI blocks a visual signature so they never read as ordinary data, plus thumbs up and down for quality.

Outcome

Both rounds shipped to beta in two weeks. People did the thing we were hoping for: they asked their own questions, then pinned them to use again.

Full case study: https://www.twine.net/signin

![Dealfront Dynamic Lists and Views](https://www.twine.net/signin

Dealfront lists update every hour as new companies match. Sales teams needed to slice one list many ways. “MedTech with low engagement” and “MedTech tagged Manufacturing” are two questions about the same list.

The only way to do that was to build another list. That caused three problems. People rebuilt the same criteria by hand. The copies drifted apart, because each one updated on its own. And the sidebar filled up with near-identical lists.

Research pointed at the real need. People wanted several views of one list, not several lists.

What I did

• Treated filters and columns as one thing. Together they answer a single question: what am I looking at. So they save together, as a View.
• Tied every View to its source list. The list stays the single source of truth. Nothing forks.
• Made the save modal show its contents. It names the filters and columns being captured, with counts, so the idea lands without a tutorial.
• Kept the state visible. Removable filter chips under the toolbar, a dot on the filter icon, and a “Modified” flag on the view selector so nobody overwrites a view by accident.
• Tested structures before engineering committed. I prototyped several list structures with the sales team first, then we picked one.
• Kept the live nature in sight with a footer line: data updates every hour, plus a refresh.

Outcome

One list, many views, all in sync, because they are perspectives and not copies. The idea grew past its brief. Views became targets for alerts and workflows, so a team can be notified when a company enters a view.

Full case study: https://www.twine.net/signin

![Pipedrive interactive app panels](https://www.twine.net/signin

I owned design for Integrations and Developer Experience at Pipedrive. That means the marketplace where customers find and install apps, and the tools third-party developers use to build them. Two very different audiences in one product area.

App panels showed data from connected tools, but they were mostly read-only. People could not tell what they were allowed to do, and any small task meant leaving the panel. Only about 30% of users ever found the actions that were there.

What I did

• Put actions next to the data they act on. Object actions in the panel header, field actions beside individual fields, global actions under one primary button.
• Used progressive disclosure so the panel stays clean and the common tasks stay one click away.
• Made the patterns the same across every app, so learning one integration teaches you all of them.
• Designed it to scale across many partners with different needs.

Outcome

Action discovery went from about 30% to about 50% in the first month. Integrations that adopted the new patterns passed 68% action usage. Panels stopped being a place to look at data and became a place to get work done.

Full case study: https://www.twine.net/signin

![Pipedrive app management](https://www.twine.net/signin

This is the other half of my Pipedrive work. Interactive panels served the customers who install apps. This one served the developers who build them.

Research showed integrations were the thing trial companies cared about most, and Pipedrive was losing to mid-size CRM competitors on it. Building every integration in-house does not scale, so the answer was to make it easier for third-party developers to build deep ones themselves. The Marketplace Manager was not set up for that.

What I did

• Split the extension types. Schema-based and iframe-based extensions moved into separate sections instead of one mixed list.
• Made the options visible. Each extension type got a block with an illustration and a short description, so a developer can see what is possible at a glance.
• Simplified the add flow. Plain forms for adding a new app extension.
• Built a JSON validation component that tells developers what is wrong and where.
• Validated it with the people who would use it: product, engineering, and both internal and external developers.

Outcome

A lower barrier for app vendors to build useful integrations. The validation component turned out to be the piece developers valued most. The work also laid the ground for more integration methods later.

Full case study: https://www.twine.net/signin

![Inbank hire purchase checkout](https://www.twine.net/signin

Inbank finances purchases at the point of sale. The checkout worked, but it did not hold together. Layouts shifted between steps, the hierarchy was unclear, and accessibility was thin on mobile, where most people actually finish. On top of that sat different legal rules per country, several ID methods, and separate paths for new and returning customers.

I led the redesign across four markets as Inbank’s first in-house designer.

Four rules I worked to

• Mobile first, for real. Most people finish on a phone, so the phone set the constraints.
• Accessibility by default. Readability, contrast, and focus states were the baseline, not a later pass.
• Flow over screens. I designed patterns that adapt, not one-off screens.
• Consistency with room to bend. Countries differ on law and ID. The structure underneath stays the same.

What changed

• Money moved to the front. The figures people care about now lead the hierarchy.
• Related fields group together instead of running as one long list.
• Color points forward. It marks the action that moves you on, and nothing else.
• Layouts scale from phone to desktop without being redrawn.

Outcome

Consistent, accessible journeys across devices and markets. Less friction for returning customers. Lower drop-off and higher completion, which meant fewer unfinished applications landing on customer service. The patterns became part of Inbank’s design system.

Full case study: https://www.twine.net/signin

![Inbank customer service back-office](https://www.twine.net/signin

Inbank’s support team ran on spreadsheets and old systems. The back-office had grown by patches for years, so navigation was scattered and the UI patterns fought each other. New agents took a long time to learn it, and it could not hold the new Hire Purchase products.

I joined as Inbank’s first in-house designer and rebuilt the tool from scratch. It became the single record of every customer service case: what exists, who picked it up, and how it ended.

What I did

• Audited the whole legacy system. Every screen, table, state, and interaction.
• Talked to the people who use it. Support agents, team leads, product managers, developers.
• Used Mixpanel data to decide which workflows to fix first.
• Built a modular component set: flexible tables, customer data blocks, status indicators, action panels, filter patterns.
• Designed for speed and for error prevention. Clear data hierarchy, tables you can scan, layouts that behave the same everywhere.
• Sat with the developers through implementation, so the design survived the build.

Outcome

Faster daily work, because the layouts are predictable. Shorter onboarding for new agents. A shared component base that speeds up everything built after it. Managers can finally see what is happening. Key screens shipped, including flows for newly launched products.

Full case study: https://www.twine.net/signin