Skip to content

Find your next step.

Explore the studio

Digital services for Dublin

Plan for the people. Review how they use the result.

Softglimmer can plan and build websites, stores, business software, apps, automation and practical AI for Dublin teams. We include the people using the result and the ways they interact with it in the project brief. Our studio is in Ranchi, India. Scope, design reviews, development and handover can be organised remotely with your nominated decision makers.

Explore our work
Choose the work around the useful outcome.
  1. 01

    Identify the people

    Describe the users and the task they need to complete.

  2. 02

    Review the interaction

    Consider keyboard, pointer and other agreed input methods.

  3. 03

    Complete the journey

    Include labels, feedback and a useful next step.

An example journey, shaped around your requirements.

A feature is useful when the intended person can reach and use it.

A business may need a clearer public website, an online store, a customer application or a better internal process. The project should identify who will use the result, what they need to understand and how they will move through the task. A control that looks obvious to the person designing it may still be difficult for someone approaching it another way.

We compare the service choices before proposing the build. That may mean content and website work, UI and UX design, a connected application or a focused improvement to an existing tool. The commission needs approved information, a defined outcome and a review plan suited to the intended users.

Input methods belong in those decisions. Discuss keyboard and pointer use, relevant devices and the complete task states before approving the interface. The brief should say which journeys and review conditions are included, what evidence is available and what still needs implementation or investigation. No single demonstration establishes that every person can use every part of a product.

Put the user and the interaction into the buying brief.

01

Name the intended users and tasks

Describe the people who need the website or tool and the information they bring. Use representative tasks rather than an unexplained feature name. Identify which users can take part in review and where the brief still relies on assumptions.

02

Agree the input methods to review

A pointer can make a control appear usable while keyboard navigation exposes a missing route. Include the relevant input methods, meaningful labels and a visible way to recognise the current focus in the agreed design and implementation review.

03

Follow the task through its states

Opening a control is only part of the journey. Review selection, correction, waiting, error and confirmation where they apply. The person should be able to understand the outcome and continue, with unresolved requirements assigned to an owner.

Outputs that connect the commission to usable tasks.

01

A task and review brief

Map the intended audiences, information needs, input methods and important journeys. Record the first release, available evidence and the questions that need further discovery or a business decision.

02

Designed and implemented scope

Review representative content, controls and complete task states. The proposal names the website, interface, application or integration work included, with the editing and operating responsibilities appropriate to that service.

03

Acceptance and handover guidance

Record which journeys and conditions were reviewed, what was observed and what remains unresolved. Explain routine content or operating updates and who handles later design, technical and support changes.

An optional example: a service choice only opens for a pointer.

Imagine a service page where a visitor must choose an enquiry type before continuing. The control opens with a pointer, but someone moving through the page with a keyboard cannot reach the choices or recognise where focus has moved. The project review should follow the complete task with the agreed input methods, including selection, correction and submission feedback. This is an illustrative commissioning example, not a Dublin client, a completed usability study or a promise of universal accessibility.

Bring the task and the conditions in which people will use it.

Share the current website or tools, approved content and a representative customer or staff task. Include the person who can explain the business rule and, where agreed and available, people who use the journey. Identify devices and input methods the review needs to cover. Existing feedback can inform the brief; missing evidence should remain visible.

For Dublin reviews, use dated invitations with Europe/Dublin and Asia/Kolkata. Nominate the approver and agree feedback windows. Review labels, keyboard and pointer paths, recognisable focus and relevant task states in the actual commissioned work. Record observations and unresolved dependencies, then demonstrate the routine editing or operating task before the agreed handover.

Real website work with a stated scope.

KMS Consultancy presents a structured service catalogue and enquiry journey. Crossworld Journey combines holiday and destination information with trip enquiry paths. These documented websites are public-information references. They do not establish Dublin clients, a keyboard-use study, an accessibility certification or a measured usability result.

Questions before commissioning a user-centred Dublin project.

Is Softglimmer based in Dublin?

Our studio is in Ranchi, India. We can discuss remote work with a Dublin team through agreed reviews and written approvals. This service-area page does not represent an Irish office or local client relationship.

Does this apply beyond website design?

Yes. A store, staff tool or customer application also has people, controls and task states to understand. The brief selects the relevant service and defines its design, implementation, connections and operating responsibilities.

How will keyboard and pointer use be reviewed?

Agree representative journeys, input methods and expected states before the review. Follow the task and record observed issues, including labels and recognisable focus. The scope should identify what was reviewed and what still needs implementation or investigation.

What should we prepare for the first conversation?

Bring the current tools, intended users, approved information and an ordinary task. Explain known difficulties without assuming their cause. We can compare the service choices and define a reviewable commission with clear handover responsibilities.