Carl Ishii · Senior UX Designer
Turning Complexity Into Simplicity
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.
On this page
- Product
- XactRestore
- Focus
- Complex enterprise workflows
- Role
- Senior UX Designer
- Core team
- Product Manager, Lead Engineer, Engineer, UX
Give me the complicated problem.
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
More than one workflow. One connected product.
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
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.
02
Project Management
Supported project status, assignment, key dates, customer information, pricing, totals, notes, and the information needed to manage the work.
03
Project History
Provided a detailed record of project changes, including when the change occurred, who made it, what was affected, and what action was taken.
04
CRM: Account, Vendor, Contacts
Created and edited customer and vendor accounts, associated contacts and properties, maintained notes, and connected relevant projects.
05
User Management
Gave administrators the ability to create and edit users, maintain employee information, define roles, and manage permissions.
06
Task Management
Helped administrators create, prioritize, and manage project tasks while keeping assigned technicians informed of changes.
07
Files and Attachments
Supported project photos and documents, custom folders, file details and notes, and the documentation needed throughout the job.
Workflows, mobile and desktop
Lead Intake and Management
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.
Administrative and Management Workflows
Supported the administrative work required to manage customers, users, projects, priorities, assignments, tasks, and changes.
Field Technician Property and Job-Site Experiences
Prioritized the property, project, route, schedule, and task information technicians needed while working in the field.
Documentation, and Task Management
Connected assigned work with field documentation, photos, project information, completed tasks, and instrument readings.
Project Management
Connected project status, assignment, important dates, customer details, pricing, totals, files, history, and active work.
Automation and Integrations
Used verified intake information to create the project, notify personnel, assign a technician, begin downstream workflows, and support connected applications.
Accessibility and Product Consistency
Applied WCAG 2.2 considerations, accessible color tokens, reusable interaction patterns, and consistent behavior across the product.
Implementation-ready design
XactRestore Lead Intake
Product ManagerLead EngineerEngineerSenior UX Designer
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:
The property was the constant. People were not.
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
A long, complex intake made guided and actionable.
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.
- AddressBegin with the single identifier shared by the property, people, projects, and history.
- Match and historyFind duplicate addresses, customer relationships, existing or past customers, prior projects, and property history.
- Contact and associationConfirm who is calling and how the person is associated with the property and customer.
- SeverityDistinguish emergency from standard response.
- Job site and scopePrefill known occupancy, customer, and dwelling details, then capture access and job scope.
- Loss detailsRecord what happened, affected areas, dates, and additional context.
- InsuranceCapture available carrier, claim, policy, or self-pay information.
- Review and verifyConfirm that required information is complete and accurate before submission.
- Lead managementSubmit the verified lead into the lead-management workflow.
- Lead automationCreate the project, choose who to notify, and assign the technician.
The address connected the system
One verified address connected the property to existing or past customers, project history, contact relationships, occupancy, and dwelling details.
Urgency changed the response
Emergency and non-emergency choices made severity visible early enough to guide response expectations and team coordination.
Optional information did not stop progress
Insurance was encouraged but could be added later, allowing teams to begin the intake even when every detail was not yet available.
Completeness was visible
A final information summary grouped missing and completed requirements so users could resolve gaps without searching back through the full form.
Incomplete work was protected
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.
Intake led to the next action
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
Task coordination from the office to the field.
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
Create and manage tasks
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
Manage field tasks
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
Contractors did not need more administration. They needed the system to do more of the work.
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.
- Address-first foundationUse the verified job-site address to connect known property, customer, occupancy, dwelling, and project information before asking the user to enter it again.
- Duplicate resolutionCheck duplicate addresses and their customer relationships before creating another contact, customer, or project.
- Save DraftPreserve incomplete information for completion later and support follow-up on the sales opportunity.
- Intake validationCheck that required information is complete and accurate. A short script also helped the user read back and confirm the required details.
- Lead automationAfter submission, ask which personnel to notify and which technician to assign, create the project, and move the lead into management.
- Progressive disclosureAsk for information when it becomes relevant.
- Show required fields onlyLet the user deliberately hide non-required text fields during intake.
- IntegrationsPrepare accurate intake information for connected XactWare applications and eligible CleanClaims workflows.
How I work
Design Thinking is the foundation. Senior design keeps the larger system in view.
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.
User ↔ Product ↔ Engineering ↔ Business
Recognize
Understand the product, goals, technology, constraints, and surrounding system.
Empathize and define
Learn how people work and identify the underlying problem, not only its symptoms.
Ideate and align
Explore alternatives with Product and Engineering while the solution is still open.
Simplify
Determine what is required now, what can wait, and what the product can handle for the user.
Prototype and test
Make assumptions visible while they are still inexpensive to challenge and change.
Ship and learn
Deliver an intentional experience, then use feedback and behavior to inform what comes next.
See the whole product
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.
Keep the capability. Remove the burden.
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.
Advocate strongly. Hold the solution loosely.
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.
User success and business success are connected.
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
I design the connections, not only the screens.
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.
01
Solve it together
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.
02
Fail early while change is still inexpensive
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.
03
Ship intentionally
Software keeps evolving, but each release should feel complete, coherent, and intentional rather than unfinished.
04
Think beyond the feature
Consider what happens before and after a feature, the pattern it establishes, who uses the information next, and whether the solution can scale.