02 — UI/UX Design
We start from the user behaviour and the business metric you want to move, then work backwards into information architecture and UI. Design decisions are recorded and shared, including the ones made on judgement.
- Typical duration
- 1–3 months
- Indicative price
- From ¥500,000
A tidier interface does not, on its own, move the numbers. Which users, doing what, differently — that gets settled first. Only then do we build the information architecture and the UI.
We record and share the reasoning behind design decisions. Even the judgement calls get written down, so the direction survives being handed to someone else later.
This tends to fit when
- The screens exist, but people do not use them the way you expected
- Successive changes have left every screen following different rules
- Design quality can only be discussed internally as a matter of taste
- You want to redesign but have not decided what should actually change
Scope
- UX audit and problem analysis
- Information architecture
- Wireframes
- UI design
- Prototypes and usability testing
- Accessibility improvements
What you end up with
- A UX audit with problems and priorities
- Sitemap and screen flow
- Wireframes and screen specifications
- Figma UI files and components
- A record of the design decisions
- Accessibility findings and a plan to address them
How we work
- STEP 01
Fix the metric and the behaviour
We identify the business metric and the user behaviour immediately upstream of it. Without this there is no basis for calling anything better or worse.
- STEP 02
Audit what exists
We go through the current screens, usage data and user feedback to find where behaviour stalls, keeping observation separate from assumption.
- STEP 03
Architecture and wireframes
We start with structure. Before touching how a screen looks, we settle what is shown and in what order.
- STEP 04
UI design and validation
We build the UI and check it as a prototype, running usability tests where useful and folding the results back in.
Duration and team
- Typical duration
- 1–3 months, depending on the number of screens and whether testing is included
- Team
- One or two UI/UX designers, joined by a design engineer when implementation is in scope.
Indicative pricing
- UX auditAssumed size：3–4 weeks. Current problems and a recommended directionFrom ¥500,000
- UI/UX designAssumed size：1–3 months. Information architecture through to finished UIFrom ¥1,000,000
- Continuous improvementAssumed size：Continuous. Designing and running the improvement cycle monthlyFrom ¥400,000 / month
※ These are indicative. The final figure follows a quote based on screen count, validation scope and team.
※ Design only, or an audit only, are both fine as a starting point.
Questions we get about this service
Yes. To make sure the UI holds up, we first confirm the goal, the users, the information structure and the existing requirements.
If there's a significant problem in those foundations, we'll propose including the UX work needed to fix it.
At the start of a project we agree which user behaviour and which business metric should change.
We then combine quantitative measures — task completion, conversion, retention, time on task, support volume — with qualitative signals from user testing, interviews and observation.
We record and share the reasoning behind the significant calls, drawing on user research, usage data, business requirements, accessibility, existing constraints and test results.
That said, we don't decide everything by numbers. For brand character, beauty and emotional appeal, we make the call with a designer's eye — and make that intent explicit.
Yes. We propose the method that fits the question: interviews, usability testing, contextual observation, survey design, or making sense of data you already have.
The point is never to have done the research — it's to answer the question your decision depends on.
Yes. We account for colour contrast, text size, keyboard operation, focus, alternative text, form error messaging and reduced motion.
The conformance level and the scope it applies to are agreed at the start of the project.
Yes. We look at usage data, user feedback, operational pain points and the existing screens, and work out what to improve and in what order.
Where a UI change alone won't solve it, we also look at information structure, functional requirements and operational workflow.