Ways of Working

In my career I’ve worked in many design teams. Every time I work with a new team, I adapt my practice to their needs, as well as serving the needs of users and businesses.

Here’s how I like to break down my ways of working:

Product design

Product design is the practice of defining features and systems that adapt to user needs and behaviours over time.

The product design process requires a designer to both project into the far future to realise a company vision of a feature vision, while at the same time remaining grounded in the present where each part of a feature needs to be built piece by piece, with constant learning cycles happening throughout.

Key considerations when designing products:

Have all user types and user needs been correctly identified?
What’s the vision or business goal?
Where do the user needs and business goals align and clash?
How are you going to design and build the solution?
- Design system?
- No design system but must use existing code and components?
- Everything custom?
How often can designs and solutions be user tested and which measures are you looking for?
- Will there be adequate test-and-learn cycles?
Will any part of the solution need AB testing?
How will features morph or change over time based on user interactions?

The key difference in product design and any other type of design is the definition of how the product will behave over time. Users live with products. Static products that never change are unlikely to maintain user engagement so future-proofing by designing features that self-improve over time is a great way to approach product design.

Note: a “product” does not have and end date or deadline. Products are continually improved and iterated until they no longer serve a purpose at which point they’re scrapped in favour of better ones.

Product success is almost always measured in KPIs, which can be based on financials, user visits, user satisfaction, accessibility scores or other measures of performance over time.

Projects

Project-based design is a process you will often encounter when working at agencies or consultancies where clients are asking you to design their solution as a one-off. Some considerations from product design may be taken into account but the key difference is that there’s always a deadline or end date with a project and you have to work back from that accordingly.

The DIRFT (Design It Right First Time) method generally applies to project design. You only have one chance to get it right. That doesn’t mean the first iteration of a design needs to be shipped, it just means that when the deadline hits you’d better make sure you have something that works for users to the best of your knowledge.

Key considerations when designing projects:

Why does the client need this to be done?
What’s the user problem? (is there one?)
What are the key milestones that a client or stakeholder are expecting you to meet?
Does all of the design work need to be complete before dev starts?
Are you creating a new brand?
Are there any design systems or boiler plates you can use to get started?
How often will progress need to be reported to the client?

The dreaded JFDI (if you know, you know) will always be classed as a project rather than a product. A JFDI will almost always have a deadline, likely in the near future. If one of these lands in your work stack just get it done with minimal fuss.

Success is generally measured as a complete delivery by the project deadline, but may also include user metrics like user satisfaction obtained in user testing / user research.

Service design

Service design can be either attached to a product or a project, and is a method of understanding which design interventions may be required at a high-altitude, systemic level.

Like product design, service design is a method to define how users interact with solutions over time. The difference between products and services is that services generally have multiple touchpoints, any of which could be classed as a product. Depending on the user or business need, a service may combine digital, print, people, locations, connected devices and other touchpoints. It’s an all-encompassing method to define the best way to solve a problem, with no bias towards any interface, system or modality.

Key considerations when designing services:

What kind of time period is the service design work going to cover? (inflection point, life stage, lifetime)
Which touchpoints should be considered?
- Who will use them and why?
What is the job to be done that the service is fulfilling?
How will the service change over time?
- Will users be changed by the service?
- Will users need to interact with different touchpoints at different times?
Which design tasks need to be done or which design teams need to be engaged to fulfil the service?
How realistic is the solution to be delivered in its entirety?
Can parts of the solution be delivered and still form a working service?

Success of a service, like with a product, is measured over time with KPIs, although it’s important that KPIs for each service touchpoint are designed in a way that they do not conflict with each other to the detriment of the overall service delivery. This is a key aspect to watch out for, especially in sales-driven organisations.

Some suggestions for good working practices

Regular Developer and Stakeholder Reviews

In all projects, it’s important to have regular reviews of what’s being developed. Sometimes, changes may need to be made to the experience when built due to unforeseen technical constraints or device nuances. This is a pretty common occurrence in my experience, and can be beneficial as long as time for this was baked in when the development plans were estimated. As a UX, it’s important to push dev planners to be flexible. The developers themselves are normally happy to experiment a little, as it gives them a chance to have their input.

UAT (User Acceptance Testing)

It’s vitally important that the UX designer goes through a round, or several rounds, of UAT when the development process is nearing it’s conclusion. The UX designer, alongside a product manager and a business analyst (if present) will have the full experiential view, and it’s important to keep checking on key flows, and stay in constant communication at this point in a project. Small mistakes can have a big impact on the end experience. While some compromises are acceptable, it’s important to stay strong. Being polite, but firm when challenged is normally how I get the best results. If a great feature will take a week longer to build, but I know it increases user satisfaction by a significant margin, I’d always push for the best implementation.

Plan for Optimisation

As KPIs will have been measured after release, it’s important to keep track of them to learn whether you’ve been truly successful or not. Every digital release of any kind will require some form of optimisation when real people start using it. Here are the regular steps I take:

Wait: Assessing any product or release within a short time frame is a very dangerous practice. Users will have cycles of behaviour, and it’s good to wait until they’ve been through a couple of these cycles at least before making any judgements. On eCommerce platforms, for example, this can be two end of month payment cycles, so you can account for anomalies in a particular month.
Plan: Optimisation always needs a plan. How much needs improvement?
User test: if figures are pointing you in a direction, clarify the direction by asking real people where any issues lie
Design and A/B test: When performing optimisation, it’s always important to test a limited piece of functionality against a control. That way, you know which elements are providing the benefit. Patience is a virtue here 🙂

Hopefully this helps you to understand my mental processes, and how I work. I’m a realist, of course, but creative thinking doesn’t need to be hampered by reality. Knowing when to diverge and converge is the key to any successful piece of work.