Regardless if the service is new or old, what problem are you trying to solve.
Establish a method of analysis and user research to help validate what is known and identify gaps in knowledge.
Learn enough for you to create something to test with target users to see if the product would meet their needs.
Understand what type of limitations there are: time, cost, functionality or infrastructure.
Create a list and prioritise what will release the most value first. Understand what has the highest impact on the user and the product as a whole.
Some needs won’t be visible, so starting with less (or incrementally improving) reduces the risk of spending too long on a product feature that is obsolete before it is released.
Going live with a minimal feature set for internal and external services will help reduce the upfront design and development.
Make sure the service fulfils an end-to-end user journey. Gather user research insights and analytics to correctly identify where to widen the cohort, categorise problems and add new features for more complex scenarios.
The name and purpose of the services needs to be tested with users so that it’s clear in their minds about:
— Who it is for
— What it does
— Why it is needed
— When to use it
— Where it can be found
— How is it used
Not all services are used by the intended user. In some cases users need a trusted helper, this may be down to confidence, ability or any access issues.
More than one channel or format is needed along with the ability for others to help the user gain access to the service.
What is initially thought to be the right solution for the users might not always be true. Without user research we are designing based on assumptions.
Prove or disprove assumptions based on qualitative and quantitive research to fulfil the user need.
Start with less and learn what the minimum is by testing with users.
Analytical data helps monitor performance. It will also identify potential areas to investigate.
By understanding the data the service team can run targeted user research, change needed to a process or unexpected impact due to a change:
— Learn more about problems and user behaviour, understand impact of every change
— Visualise user behaviour and use it for targeted research
— Use data gathered to understand onward impact to wider service
— Understand how to measure success with performance frameworks
— Clear understanding of what data is needed to help inform the next feature and how to collect it
Understand if the data you need from a user already exists within the organisation.
It might be from an existing site or internal/external service. For example, bank validation and identification.
Can the design of the service make use of existing patterns that have already been validated to work.
Establish what normal looks like so when new features are introduced it highlights like-for-like change, patterns in behaviour and user feedback.
Establish long, medium and short term service goals. Accept cause/effect and that not everything is set in stone. Every goal met and releases made may create new problems.
A product team should be stood up for the lifetime of the service so that is continually meeting the needs of the user.
Forty-five Ninety (4590) is a focus on the negative space, layers and skeletal form of the Grade II listed Dunston Staiths.
Newcastle Upon Tyne
United Kingdom
info(at)a184.uk
Forty-five Ninety (4590) is a focus on the negative space, layers and skeletal form of the Grade II listed Dunston Staiths.
Newcastle Upon Tyne
United Kingdom
info(at)a184.uk