01
Lead Intake and Management
Captured the information needed to create the customer account, contact, and project, then moved the new lead into management and automation.
Carl Ishii · Senior UX Designer
A brief overview of the enterprise products, workflows, and design decisions I worked on at Verisk.
Because the products are proprietary, I do not reproduce Verisk screens or internal artifacts here. This is not a conventional case study. It shows what I worked on, how I approached complex product problems, and why I made selected design decisions.
The more complicated the system becomes, the more interesting the UX problem becomes.
I enjoy the work that happens before the answer is obvious: understanding the system, finding the real problem, bringing the right people together, and turning complexity into something users do not have to think about.
What I worked on at Verisk
My work extended from project operations and financial information to customer records, user administration, permissions, intake, office task coordination, and field-technician workflows.
Features, mobile and desktop
01
Captured the information needed to create the customer account, contact, and project, then moved the new lead into management and automation.
02
Supported project status, assignment, key dates, customer information, pricing, totals, notes, and the information needed to manage the work.
03
Provided a detailed record of project changes, including when the change occurred, who made it, what was affected, and what action was taken.
04
Created and edited customer and vendor accounts, associated contacts and properties, maintained notes, and connected relevant projects.
05
Gave administrators the ability to create and edit users, maintain employee information, define roles, and manage permissions.
06
Helped administrators create, prioritize, and manage project tasks while keeping assigned technicians informed of changes.
07
Supported project photos and documents, custom folders, file details and notes, and the documentation needed throughout the job.
Workflows, mobile and desktop
Started with the job-site address, connected the people and property, captured the loss, verified the information, created the project, and moved the lead into management.
Supported the administrative work required to manage customers, users, projects, priorities, assignments, tasks, and changes.
Prioritized the property, project, route, schedule, and task information technicians needed while working in the field.
Connected assigned work with field documentation, photos, project information, completed tasks, and instrument readings.
Connected project status, assignment, important dates, customer details, pricing, totals, files, history, and active work.
Used verified intake information to create the project, notify personnel, assign a technician, begin downstream workflows, and support connected applications.
Applied WCAG 2.2 considerations, accessible color tokens, reusable interaction patterns, and consistent behavior across the product.
Implementation-ready design
Lead Intake is a guided workflow that helps restoration teams capture and verify the information needed during an initial loss call, from the job-site address and customer relationship to severity, scope, and insurance. It turns that information into an actionable lead that can create a project and begin the next steps. UX, Product, and Engineering worked together throughout the process, combining user research, product and business requirements, and technical knowledge to shape the final experience.
Delivery status: The final Lead Intake experience was prepared for Engineering.
Research revealed an important relationship:
Owners, tenants, property managers, onsite contacts, and insurance relationships could change over time. The job-site address was the finite piece of information they shared, so it became the starting point and the common link between the property, people, projects, and history.
Final Lead Intake experience
The experience began with the job-site address. It identified duplicate records, connected existing or past customers and projects, and prefilled known occupancy, customer, and dwelling details before the intake continued.
This was more than a change to the form. Engineering reconstructed the database and backend so the address connected the property, customer relationships, project history, and new intake.
One verified address connected the property to existing or past customers, project history, contact relationships, occupancy, and dwelling details.
Emergency and non-emergency choices made severity visible early enough to guide response expectations and team coordination.
Insurance was encouraged but could be added later, allowing teams to begin the intake even when every detail was not yet available.
A final information summary grouped missing and completed requirements so users could resolve gaps without searching back through the full form.
A persistent Save Draft action supported interruption and uncertainty during an initial loss call. It also gave the contractor an opportunity to follow up on the sale.
The experience connected captured information to immediate downstream work, including task creation. These actions were designed for automation so the system could reduce the administrative burden on the user.
Designing across roles
I also worked on task experiences for two different working contexts: administrators coordinating the work and technicians carrying it out in the field.
ADMINISTRATIVE EXPERIENCE
A task-creation and management feature for administrative users coordinating work. The administrator managed the project, created and prioritized tasks, and the application notified the technician of changes.
TECHNICIAN EXPERIENCE
A technician workflow that prioritized relevant task, property, and job-site information in the context of field work. The technician completed tasks, collected job-site information, documented the work, and recorded instrument data.
These experiences required the product to support different responsibilities and environments while maintaining a coherent task model.
Reducing administrative burden
Research pointed toward a larger opportunity: use automation to reduce the administrative work surrounding intake.
The goal wasn't automation for its own sake.
It was to give contractors more time to focus on customers and profitable work while reducing unnecessary administrative effort and the potential for downstream rework.
The final design included Save Draft, validation, duplicate review, project creation, personnel notifications, and technician assignment. The remaining concepts show the broader direction explored for reducing administrative work.
How I work
I use a familiar human-centered process while continuously considering Product, Engineering, technical reality, business goals, effort, and what today's decisions may affect next.
Understand the product, goals, technology, constraints, and surrounding system.
Learn how people work and identify the underlying problem, not only its symptoms.
Explore alternatives with Product and Engineering while the solution is still open.
Determine what is required now, what can wait, and what the product can handle for the user.
Make assumptions visible while they are still inexpensive to challenge and change.
Deliver an intentional experience, then use feedback and behavior to inform what comes next.
Advocate for the user. Understand the business. Design for both.
Senior design looks beyond the screen. I consider user needs, product strategy, engineering effort, and how today's decisions shape tomorrow's product.
Make complexity feel simple.
The system can be complicated. The experience should not be. I ask what users need now, what can wait, and what we can eliminate or automate.
Research gives us evidence. Collaboration gives us better answers.
I advocate for the user, not my first design. I challenge assumptions, surface technical opportunities, and work with Product and Engineering toward a solution the team owns together.
My responsibility is to advocate for the user, but user success and business success are not independent. A product that fails its users cannot sustain the business. A solution the business cannot sustain cannot continue creating value for its users.
That is why I look beyond the interface to Product, Engineering, technology, effort, cost, strategy, and the business itself. The job is to find the solution that brings those needs into alignment.
What I bring
Senior UX is not only about solving the interface. It is about bringing the right disciplines together, learning before change becomes expensive, and making decisions that strengthen the whole product.
Bring Product, Engineering, and UX into the problem while the solution is still open. Giving each discipline a voice creates shared participation, shared ownership, and a better product.
A prototype is not there to prove the design is right. It helps the team find incorrect assumptions, learn, adjust, and test again before the cost of change grows.
Software keeps evolving, but each release should feel complete, coherent, and intentional rather than unfinished.
Consider what happens before and after a feature, the pattern it establishes, who uses the information next, and whether the solution can scale.