My transition from product design to service design

systems thinking and service design model by Martin Sandstrom.


2022 was the year when I realised that I cannot succeed in my current role at Legal & General unless I adopted the mind and skillset of a service designer.

This was not an epiphany. I didn’t wake up one morning and thought ‘I need more service design in my life!’. I’ve been working with digital products and services since 2007 and my career path has followed a typical trajectory of starting hands-on, learning the ropes and adding enough experience to start seeing the mechanics of the system. And once I started to ‘get it’ all of a sudden it became less and less interesting to work with surface level UI challenges.

More and more, system design was what really interested me. Business models, value propositions, designOps and service design. So one can say that the interest for system thinking and service mapping had existed for a while. Although I had practised service design here and there in my roles as a product designer I had not yet been in a role as a service designer.

And there is an important difference.

Doing service design and being a service designer is not the same thing. I had to learn this the hard way.

From UX to EX

When I joined Legal & General in 2021 it was to fill the role of senior experience designer. I assumed the work would be things like requirements gathering, user research, product design and testing for our customer facing self-serve portals etc. The typical UX stuff.

But after I joined I was immediately given the sole responsibility to work on our internal systems, services and products. This was a new area given to the division and important enough to dedicate a full time designer on it. What ‘it’ referred to was less clear. Slightly outside the comfort zone for a contractor like myself who’d normally request or co-create a very clear brief and statement of work before any work will commence.

Turns out ‘it’ had something to do with the fairly recently coined term Employee Experience (EX), which was the natural progression after employee engagement. The HR community had realised that employees could benefit from a more holistic approach, similar to the one applied in Customer Experience (CX).

So off I went, farther and farther away from my comfort zone, looking to create my own brief whilst reaching out to people who had titles sounding like they had something to do with EX. All remotely, of course since we were in the midst of the pandemic.

Writing your own brief when you don’t have a budget, remit or even a name and reputation that means anything to anyone, is a bad idea. You won’t get anything done. I did a bit of user guides, intranet pages, EX research and principles work, tried to get some traction in an EX strategy and collaboration between departments, but in the end it was a pretty weak existence. It was not something I was used to but indeed a sober wake-up call.

Product design has a very limited area to operate in in the world of EX where the organisation doesn’t own any of their employee facing products. And this is where my mindset shifted to service design.

What’s the difference between product and service design?

Think about it this way; screen design is very much a tangible thing. The information architecture, user flows and content strategy are less tangible but still pretty easy to understand with good visualisation tools. All of this is backed up by user research and the goals that are defined for the product. That’s product design in a nutshell, right? Who delivers these things? The product design team normally (read my take on the design dream team here).

Now let’s take a look at a service: Onboarding a new employee when they join a company. How do you design this service? Immediately we realise that a service design team can’t be the ones delivering this, because the service has a lot of interdependencies between teams and divisions such as HR, Finance, IT fulfilment, IT support, Security, Employer brand and Legal. All of these teams might no be hands-on when the employee joins but they will have been involved at some point on process or policy level.

This is why service design is intrinsically co-creative. Although a service design team might be responsible for delivering the blueprint, or solution, it never happens without the involvement of the teams that the solution will feed back into. A product team will no doubt involve other teams in the creation of the product, but in the end they will be the owner of the solution. That’s not the case in service design. The solution is co-owned by many teams and everyone needs to be onboard.

Despite the title, service designers don’t do design. We don’t own design decisions and we don’t do design in the traditional sense that many of us are used to from previous roles.

A service designer’s job is to facilitate the orchestration of systems to produce human-centred, positive change.

We’ll get back to that definition in a bit.

Why is service design so difficult?

Compared to service design, product design is easy. There is certainly an overlap and no digital products live in a service-less vacuum. There’s a service behind every product. But the part of product design that isn’t bothered about the service processes that support it is comparatively easy.

Why?

Because a product team is (at best) a self-sufficient task force on a mission to deliver, and everyone is working towards the same goal. Introduce more teams, more policies, more agendas and your road bike just got swapped for a tricycle. Because things get exponentially harder the more people involved. People make things messy and complexity rises.

As a service designer you’ll be introducing teams to new ways of working, encouraging them to collaborate for the benefit of the user and slowly nudging the system towards a new state. Unless you have a senior management sponsor to push things along with sticks and carrots it can sometimes feel like an impossible task.

When teams don’t show up to workshops, critical decisions get put on indefinite hold and every step you explore in your process map opens up three new ones, owned by teams you’ve never heard of, it’s very easy to settle for some ‘quick wins’ on UI level that you can actually control. Erik Flowers puts it beautifully in his modern classic on Medium. I can relate to every point he makes, and sadly say that it’s still very true in 2023.

What skill set do you need to dial up when you transition into service design?

If you’re not put off yet and you’re still up for the challenge, here are some tips on what to focus on from my own experience. Here’s my definition of the service designer role again:

A service designer’s job is to facilitate the orchestration of systems to produce human-centred, positive change.

Let’s dissect that definition to better understand what’s asked of us when we step into a service designer role.

To facilitate:
Make (an action or process) easy or easier.

The secret sauce that service designers often bring to a project is to be the glue/catalyst/mediator between different stakeholders. We see this all the time. Everyone is busy in their own part of the world and along comes a change initiative that forces different teams to either start talking to each other or feel the pain later. Sometimes there isn’t even a change initiative from above and you have to work laterally in the organisation without any sponsorship. That’s really when these skills become a life saver.

As a facilitator you help those conversations along, by building rapport with teams, running workshops, agreeing accountability and setting up transparent communication channels. Workshop skills are hugely beneficial here, but also the importance of soft skills like patience, empathy and confidence cannot be emphasised enough.

Orchestration of systems:
The planning or coordination of the elements of a system to produce a desired effect.

This is where the plan of action is shaped. It happens mainly with visualisation tools like process maps, user journey maps, service blueprints and prototypes. Learn them, feel confident in using them and don’t get too bogged down in design methodologies and theory. Early on I spent a lot of time trying to figure out if I should use a process flow or a journey map. A blueprint or a system map. But it really doesn’t matter. They’re just slight variations of the same thing with different names, i.e. a model of a system that will help you and your stakeholders align and focus on the right thing, in order to know what to do next.

These maps are not deliverables, they’re just tools. They should evolve over time so don’t spend too much time perfecting them. You can wing it. Start small and add to it as you learn more. My maps are Frankensteins created from all sorts of diagram theory. But they get the job done.

Mapping exercises takes place in many different settings. You can map on your own, you can co-create with end-users by showing them a draft and let them tweak. You will co-create to-be and as-is maps in workshops with your stakeholders, and you might sit down with a subject matter expert and iron out parts of a map in a 1-2-1.

To get to grips with the all the bewildering theory my first port of call would be the bible-like status, go-to resource for all service designers; This is service design doing. From there the list of literature is endless, but that’s for another post.

Human-centred:
Computers, technology, systems, etc. that are designed to work in ways that people can easily understand and learn.

If facilitation is the secret sauce we bring to change projects, human-centred thinking is what separates us from business analysts and solution architects. The skills needed here, part from the mindset you probably already possess, lie within user research. Human-centred design without user research doesn’t exist. Even if you simply do best-practise usability and accessibility you’re still applying someone’s recommendations that were derived from research.

If you don’t have a researcher on the team you’re likely the one specifying the research goals, creating the plan, collecting the data and synthesising the results. So it’s very useful to pick up skills in user research from a professional source. There are many pitfalls.

Positive change:
Changing something for the better.

Not as much a skill as it is a virtue, but a moral compass will help shaping you long term. In service design you often get to work on larger change projects than in product design, and they can have a large impact on people, animals and environment. Considering the big picture is a cornerstone of systems thinking, and we need to remember that doing the right thing for one part of the system could have a negative effect somewhere else.

For a completely hypothetical example, changing from fossil fuel to green energy is great to combat pollution, but if the solution is more off-shore wind farms that affect the marine life in a negative way we have to think again. Stay true to your moral compass and often switch lens to zoom in and out to better understand the intricacies of the system and how it will respond to change.

To conclude

You can definitely make the transition into service design from product design, just be prepared for what’s to come. It’s slow, it’s messy, it’s political. But it can also be very rewarding. I’m just at the beginning of my transition and we’ll have to wait and see if I’m just here to dabble and then return to product, or if it catches on and I make a full transition. Either way, what I’ve experienced so far has taught me a lot and forced me to grow so I encourage anyone who’s interested to go for it. Be patient, and be kind to yourself and your stakeholders along the way.

artwork

Digital Product Dream Team – The Optimal Team Structure in Software Development

What does your product team look like?

Would you change anything if you could?

As part of agencies and in-house teams I’ve seen many different takes on product org design. Things got done one way or the other, but the teams were often far from optimised and it wasn’t always without friction. I saw a lot of overlap in skill-set, and role descriptions that narrowed down people’s responsibilities to a sub-set of their true potential.

It’ll become apparent that this article is written by a former UX designer (former not because I’m retired but because I refuse to use that title any more). Too often it’s a role being shoehorned between other roles when it shouldn’t be there in the first place.

To figure out what skills we can shuffle around and get a more optimised team we first need to look at our building blocks.

The typical roles involved in digital product design

Let me list some typical pre-development product team roles and what they are often expected to be in charge of.

Delivery / Project manager

  • Plan activities and timings
  • Coordinate and scope team effort
  • Manage client and stakeholder expectations
  • No issues here, they usually let us get on with work

Product owner

  • Product strategy and roadmap
  • Manage 3rd party relationships
  • Track performance
  • Final say and sign off

Design strategist / Business designer

  • Typically an agency role overlapping product owner, user researcher and UX designer
  • Functional and business requirements
  • Product strategy
  • Content strategy
  • Research

UX designer

  • User research and testing
  • Functional requirements
  • Journey mapping
  • Information architecture
  • Content strategy

UI designer

  • UI and visual brand exploration
  • Design system management
  • Visual & Interaction requirements
  • Production design

Business analyst

  • Functional requirements
  • User stories and sprint preparation
  • Acceptance criteria

Usually backed up by:

  • Head of design / Creative director
  • User researcher
  • Copy writer
  • Quality Assurance tester

And to make the list complete I’ll also include the dev roles I’d normally work alongside:

  • Front-end developer
  • Back-end developer
  • Systems architect
  • DevOps engineer

You wouldn’t normally see a team with all of the above roles. Some are more common in-house and some are more agency related. It’s also not uncommon that one person straddles multiple roles. I’ve had product owners also acting as delivery managers, QA being dealt with by the dev team and UX designers doing BA tasks.

None of these roles are superfluous when combined correctly. They all possess unique skills that can be utilised with minimal overlap in an optimised team structure.

The question is; what is that structure? I think the answer is in the design process:

Discover, Define, Design, Develop.

Four distinct phases to product development, each of which requires unique skills. Let’s examine them and see what those skills are and what roles they might translate to.

Skills required for each step in the design process

Diagram showing the ideal digital product team structure and roles.

Discover

This phase is characterised by problem/opportunity definition, business requirements gathering and market and user research. Skills you want here are product strategy, workshop facilitation, quant and qual research. The define phase could be a joint responsibility of a product owner and a researcher, or it could be handled by someone possessing both skill-sets.

We haven’t talked about the service design role up to this point, as it’s less to do with product development and more with organisational change. But if we look at the service designer’s toolbox we find all of the above mentioned skills.

Having said that, the product owner is essential to any product team and for that reason I’m inclined to say that a product owner with service design background would be my go-to candidate for the Discover phase. If it’s a large project and there’s budget for it they should probably take use of an external research agency, because research, as we know, is a time-consuming activity.

Define

Define is a proportionally short phase in the process. I considered merging it with the Discover phase, but in doing so I would’ve missed out on a crucial step. Once the discovery phase come to an end and presents its synthesised body of work, it’s the job of a strategist to decide how to proceed to achieve a desired outcome.

In one company I worked for, the discovery phase had presented a market opportunity to build a product that brought all household bills into a consolidated view. In this case the product owner was the one picking the way to market, deciding that we’d initially focus on the flat sharer segment, and due to the nature of the service would serve them via a mobile app. He could’ve chosen 100 other routes to market but this was his product strategy.

The point I’m making with the above example is that Define is extremely important since it will shape all the work thereafter. For that reason I’m choosing to break it out from Discover. What you need here is an experienced and visionary person who can spot market trends, use data to form an opinion but also trust their gut feeling. Finally they need to be able to communicate the strategy and inspire the team. This is not a small feat and it must land on the product owner’s list of responsibilities.

Design

Once the product strategy has been decided we enter the Design phase, which includes design exploration, concepting, information architecture, technical feasibility, design system development and screen design. Some of these tasks might happen pre-development while others happens alongside development in an agile manner.

We need skills like IA and systems thinking, visual UI design, interaction design and possibly animation, UX writing (i.e. UI focused copy writing), prototyping and usability testing. There’s a lot to cover in the design phase, and that’s why it has traditionally been broken into UX (function) and UI (form). However, if you have come across my writing before you know I’m not a fan of this separation and I much rather hire “full stack” product designers capable of doing all of this. I’d also get copy writers who can span everything from marketing to UI copy.

In reality it’s hard to find designers who can do it all, and you should consider a split between UI designers (or product designers if you like) and system designers. The UI designers do the product architecture and design from concept to screen layouts and testing. The system designers own the design system, including interaction design, visual styling and accessibility guardrails.

This means that for screen designs there will be close collaboration, but in an ideal world the UI designer can build the pages with existing components, and when components are missing they can request them to be added to the design system backlog.

Develop

In terms of development I’d be stepping out of my remits to say what the ideal team structure is. I normally work closely with developers, solution / system architects and business analysts and what stands out to me here is the business analyst (BA). As a UX designer I’ve always had a large overlap in duties. If there’s one in place I can be a lot less rigid in my documentation and trust that all requirements will be neatly added to the sprint backlog. If there isn’t one in place I have always made sure that the visual and functional UI requirements have been fully documented in a consistent format.

Can we afford the luxury of a BA on the team, or should we let the UI designer document their designs as user stories including acceptance criteria? This is an elaborate task, so for now I’ll keep a BA on the team and include them in the design phase by taking the product owner’s direction and translating it into product requirements and design briefs for the UI designers.

This way the BA becomes the interface between designers and the rest of the team. This doesn’t mean that design happens in a black box where designers never discuss with developers or business, but it can be a great relief to be able to fully focus on design and should in theory remove friction for the team.

What about designer/developers?

I was also considering bridging the gap between design and code by using front-end developers who are skilled in UI design (and basically exclude UI designers from the team). But skilled is not enough – most front-end devs know how to apply UI design theory. The developers I work with take a real interest in the usability and usefulness of the end product. But what they really care about is writing great code. Most developers that care enough about design to be great designers eventually jump the fence and become designers full time. The days of the web-designer is over, and the few that can generate both great design and great code are not called unicorns without a reason.

Summary

Looking at my dream team I realise I have made myself more or less redundant. But I guess I knew that was coming. My title was UX designer for a long time, and I don’t think UX designers should exist. If this was indeed my team I reckon I could either lean on my service design knowledge and be the product owner, or I could be the UI designer.

I’m keen to hear your thoughts on this theoretical team structure. Would it work in reality? Would you fit in? What does your dream team look like?

Lumix GX80 and M43 prime lenses

My M43 Camera setup – Lumix GX80 with prime lenses for Micro Four Thirds system

My camera is Lumix GX80.

It was released in 2016 and in 2019 when I bought it, it was a bargain. I bought it because I wanted to improve the image quality of globalkitespots.com, but also because an interest in photography in general had started to grow in me.

I’m the kind of person who does hours and hours of research before I buy something. The world of digital cameras is probably one of the most opinionated and documented gadget driven hobbies there is, so there was definitely no shortage of material to immerse myself in.

I wanted a system camera for the versatility of changeable lenses, that much I knew. I also fairly quickly narrowed it down to a mirrorless APS-C or Micro Four Thirds camera for the small form factor (essential for documenting my kitesurf trips while traveling light).

After a number of hours I’m too ashamed to fully disclose I had finally landed on the GX80 by Panasonic. It just felt right, despite not having tried any of the models I’d considered. For me, the value offered with the GX80 couldn’t be beaten. The smaller size and cheaper price tag of the M43 lenses compared to APS-C was the winning factor. Although Olympus has some attractive models like the PEN-F, it was the cheaper price and my positive experience with Lumix cameras in the past that sealed the deal.

What alternatives to Lumix GX80 have I considered?

After two years of shooting with the GX80 I’ve learnt a few things of how I shoot, what’s important to me as a photographer and what I want from my camera.

From the GX80 there are two possible routes I’ve considered. One is to opt for even more portability and go for the tiny Lumix GM1. The advantage would be that I already have compatible lenses, and the reduction in size and weight. But it would still not be pocketable with a lens mounted, so that advantage is only minor.

The battery wouldn’t last as long as the GX80, but the biggest downside was something I only discovered after using my GX80 for some time. I don’t use the viewfinder much and I could live without it, but what I love with the GX80 is the tilt screen that lets me shoot with accuracy from the hip. The hip angle has totally become my thing for street photography and I would hate to loose it.

The other way I could go is up. Up in sensor and lens size. Since I picked up photography I’ve always had a soft spot for Fujifilm’s X-E series. It’s basically the equivalent to Lumix’s GX series but a bit more purist. Unfortunately the earlier versions don’t have the flip screen, and the latest X-E4 is simply too pricey at the moment. On top of a pricey camera body I’d also have to invest in new and costly lenses. Why would I do that? Simply because the larger APS-C sensor would offer shallower depth of field for the same view angle – and who doesn’t love shallow DoP? If there’s one thing that makes the photography community drool it’s BOKEH!!! 🤤🤤🤤 Hey, count me in 🤷‍♂️

Sony’s 5000 and 6000 series also look like they’d serve my needs well. They’re compact, got tilt screens and raving reviews. I might give Sony or Fujifilm a go at some point in the future, but for now I’m happy with my current set-up.

Now, let’s take a look at the lenses I use.

Prime lenses for M43

I only shoot prime. Not because I’m a camera snob, but for one it’s a smaller form factor, and two they are generally faster i.e. lower aperture. And what does low aperture give me? More BOKEH!!! 🤤🤤🤤

It’s no joke. With the smaller M43 sensor I have to make my lenses work hard to achieve shallow depth of field, and most photos I take benefit from separating the subject from the foreground and background. I love layered photos and often add depth by including an object at the very front of the image.

Hunting for prime lenses to add to my collection was great fun in the last two years. There could still be some old telephoto lenses I might want to get in the future, but for now I’ve got five lenses to cover most of my needs. With a bit of patience I got each of them for £100 or less on ebay, and that’s the beauty of M43. What other system can give you that!?

Lumix 20mm f/1.7 II

This compact pancake wonder is my everyday shooter. It’s the perfect compromise between view angle (40mm equivalent), DoF and size. This lens is my go-to for street and indoor photography. The auto focus allows me to capture things in the moment.

Lumix 20mm f/1.7 II on GX80

Lumix 14mm f/2.5

This extremely compact lens is great for when I need a bit more wide-angle. Dinner parties, kite beaches with subjects in the foreground and layered landscapes. This is also my lens for shooting travel documentaries on the GX80, although I prefer GoPro style action cameras for that. It’s nice to have, but it’s my least used lens since it’s the same focal length as my iPhone and doesn’t offer that much more in terms of image quality.

Olympus M.Zuiko 45mm f/1.8

The Olympus 45mm is a 90mm full frame equivalent portrait lens. I don’t shoot much portraits but rather use this for anything from product to landscape and street. I love the long focus and shallow depth of field that really put emphasis on the subject. Telephoto is great for capturing people a bit more candidly from a distance. It also helps for landscape with a subject far away. The lens is also auto focus which makes it versatile.

7Artisan 25mm f/1.8

This was my first lens for the GX80. The 50mm equivalent focal point and manual handling took me a while to get used to, but it was great fun to start like this since it made the shooting more analogue and craft-like. Once I had my auto focus lenses I used the 7Artisan way less for people photography. I’ve kept it only for one reason really, but a good one. Watch photography. I found that it’s by far the best lens I have for watch photography thanks to it’s short focus. And I do watch photography a fair bit. Sometimes I use it for other types of product photography and mood-infused stills because the bokeh is really nice and creamy.

7Artisan 25mm f/1.8 on GX80

Fujian 35mm f/1.7

Finally this guy. I call this my arty lens. It’s a CCTV lens that you can pick up for £25, but the quality is really rather decent and the way everything except the subject is out of focus is quite a nice effect for some type of photos. I use this for street every now and then, and because it comes with extra focal length adjusters I’ve taken some great macro watch images with it as well.

What’s next?

Because of the affordability of M4/3 lenses I’m constantly on the hunt for interesting lenses to add to my lineup. For what I do, I don’t think I need to add much to what I already have, but out of curiosity I keep looking for funky little manual lenses converted for M4/3.

I recently tried the latest lens from TTartisan, a Chinese company focusing on affordable manual lenses. They have a lens that sounds amazing on paper: 17mm 1.4. Basically a bit more wide-angle than my 20mm Lumix, but with shallower depth of field. It sounded like a great street lens.

The TTartisan wasn’t for me.

It wasn’t bad, but I quickly realised how amazing the 20mm lens is after spending a weekend with the TTartisan. It’s heavier and larger than my other lenses, but didn’t offer anything my 20mm can’t do. So off on ebay it went. But I’m glad I tried it, and I’ll keep trying more lenses in the future. Especially for street, it’s like rediscovering your city with new eyes – and who doesn’t like that?

Abstract illustration of business purpose

What’s the purpose of a business? To create value or profit?

The sole purpose of a business is to sustainably deliver value.

The sustainability part is important here because this is how the business stays afloat. It’s the enabler of the value delivery. It’s done by receiving something in return for the value delivered.

In practise, it’s being profitable. Making money.

I used to think that the purpose of a business was to make money, period. But of course, all great companies have a vision and that vision is never about making money – that’s just a result of being successful while working towards the vision.

So, is the company purpose to act on its vision?

The vision is about value. In the end we all want to make the world better in one way or the other. Many will succumb to greed, but I wholeheartedly believe that even the greediest person in the world still has a moral compass that tells them what the right thing to do is. They may not act on it, but if they could find a win-win to get rich while improving the lives of others, they would prefer this option.

In literature we read a lot about the value part of the business purpose. In theory it makes sense to start with Why, to be Driven by purpose, to join the Purpose Revolution, to be a Vision Driven Leader…

But too often when you’re waist deep into a project, the vision has seemingly vanished from people’s minds and the focus is on reaching the financial targets for the quarter, incentivised by a tantalising year-end bonus.

Vision is good, but money talks.

In theory it’s all about the vision. In practise, I find, it’s all about making money. So over the years, because I’m a no-BS person, I adopted the pragmatic money-making approach.

We’re a business, not a charity, I used to think. But I knew that couldn’t be the whole story. Too many books said otherwise. Books I agreed with in theory. Living like the Wolf of Wall street might be awesome for a while, but it’s not sustainable long-term (literally, but also for company growth).


The coexistence approach – one leg in profit, one leg in value

When I joined Legal & General, I learned about their vision – Inclusive capitalism. This resonated with me, because for the first time I saw a vision that combined value and profit. As a financial institution mainly focused on capital investment you have to include profitability in your vision if you want to keep a straight face. But equally important in the vision of Inclusive Capitalism is HOW you invest. Investing in profitable projects that bring value to people and improve lives is the purest form of delivering value in a sustainable way. The company IS the enabler of value delivery.

So thank you, L&G, for helping me come to terms with my profit-driven self. It’s never about profit or value alone. They need to co-exist. It is a simple idea, but it needed to be articulated to sink in.

Light sipping into a dark room from an open door.

Want to become a UX contractor? Get comfortable with uncertainty

Working as a contractor in digital product design is amazing. You’ll get to be in control of your work arrangements while charging rates usually a fair bit higher than permanent employment offers. These high rates compensate for unpaid annual leave and lack of pension schemes, and cover running costs such as insurance and accounting.

But if the steady routine of a regular 9-5 job year after year doesn’t suit your lifestyle, and you’ve got a bit of financial acumen, my experience tells me that being a contractor offers you both freedom and good finances. On top of that you’ll need to keep pushing yourself to stay relevant, and in return you’ll get to work with new clients, expand your professional network and constantly learn new things.

The most common reason against contracting and freelancing is the financial uncertainty. Having a bit of downtime between contracts can be both a blessing and a curse. You need to get comfortable with this uncertainty if you want to become a contractor.

But here’s the kicker – the same uncertainty you’ll get comfortable with when going free agent is the uncertainty you’ll need in order to grow as a person. It’s the uncertainty you’ll feel outside your comfort zone.

Get comfortable with uncertainty and grow as a person

Growth only happens outside your comfort zone, as the old adage says. And the reason it’s uncomfortable out there is because success is not guaranteed. The outcome of your effort is uncertain. In fact, it’s fairly certain that you’ll fail more often than succeed – and this is what we need to address, because inherently no-one enjoys failing.

What it comes down to is as simple as this: You have to raise the bar to grow, and you have to accept and even embrace failure as you do so. That try-fail-analyse-adjust feedback loop is essential for improvement.

But as we said, failing is painful and putting in the effort to fail and improve is something our lazy, comfortable brains rather avoid. So we have to negotiate a bit with them. Give them a comfort blanket to hold on to as we step out of the comfort zone.

Give yourself a comfort blanket

If you’re learning to backflip, a comfort blanket is probably something to prevent pain and injury, like a foam pit, or a person spotting you. But what’s your comfort blanket for pushing your career? How do you gain confidence to pursue contracting, change career path or start a new business?

I’ve been moving around since I started consulting in 2015. Never knowing where I’ll be next. Not knowing where my career is going even, with all these possibilities and no obvious What to my Why. It was scary before I took the leap, but once I got going I quickly gained confidence in my newly found freedom and embraced the uncertainty. How did I do this?

The key to be comfortable with uncertainty as a contractor is to have a financial buffer, little financial commitments and to have confidence in the value you bring to a project.

Have a financial buffer

If you have enough liquid funds to maintain your lifestyle for a few months without income you’ll feel a lot more comfortable leaving your current job, or moving from contract to contract. There will be downtime as a contractor. Sometimes only a few days, sometimes months.

Three months of buffer to cover essential expenses like rent and food is a recommendation I’ve been following for years. You could probably get by with less if you had to, and most likely you’ll get back on your feet before three months, but give your buffer a buffer and your worrying brain will feel better.

But don’t overdo it. These are funds that need to be readily available so you can’t lock them into long term investments or jeopardise them in the stock market’s ups and downs. These funds will do little to nothing to build your wealth, so you really don’t want to put aside more than necessary when it could be working hard in your investment portfolio.

Have little financial commitments

Personal financing’s most basic rule is ‘bring in more than you spend’. In order to get past those dry months of no work, planned or unplanned, it’s obvious that the less expenses you have, the smaller buffer you need. For Europeans in general, and me in particular, the idea of overspending and living beyond one’s means is a bit odd. I only live a lifestyle I can afford using cash, and the only loan I’m likely to take is a mortgage. Living on credit has its benefits, but it ties you down financially which can be very stressful if you’re contracting.

Short-term leases and pay-as-you-go plans is the way to go if you want to remove financial stress. An ability to cut down on luxury if needed rather than being locked into interest-invoking financial agreements is to recommend, and feels amazing. It’s not always the cheapest option so personally I weigh my options carefully, thinking of both long-term gains and short-term flexibility.

Have confidence in the value you bring to a project

There’s no right or wrong time in your career for becoming a contractor. There are contractors of all levels of seniority, but what they all (should) have in common is that they’re good at what they do and they get the job done.

The more sought after your skill set is and the more value you can bring to a project, the more you can charge. It usually helps to have a few years of experience under your belt, and even better if you have a niche where you have documented expertise. Clients love to work with contractors with experience in their domain. It means that you can hit the ground running and you can speak the same lingo from day one.

As a parenthesis, clients also love to see some big brands in your portfolio. This is a bit of a fallacy though, since simply working for a recognised brand doesn’t make you a star designer. If you’ve worked there as a contractor it’s likely that you were there to work on campaigns or internal tools rather than the flagship products. Companies like Apple, Google and Amazon do have a rigorous hiring process though. They don’t hire bozos, so at least it means that you passed the high standards of the interview process.

I started out as a general designer of digital products and gained experience from a variety of domains, companies and methodologies. After eight years I became a contractor but continued being a jack-of-all-trades. After 15 years in digital design I now know what I bring to a project. I can quickly gauge whether I’d be a good match for an advertised role. I know what I’m good at and I know where I lack experience. I tend to work more with system thinking and product strategy nowadays. I know a lot about designOps but I lack experience in managing people.

Knowing what I’m good at, how I integrate in different teams and the value I bring to a project gives me confidence when I’m looking for new contracts. This confidence in my own value is important because without it it would be a lot more stressful when a contract is coming to and end.

So, are you ready?

Part financial guidance, part personal development, I realise this post might’ve digressed a bit. But the main point still remains – contracting can support an amazing lifestyle, but you should prepare yourself for the uncertainty it brings. Also, read these practical tips by Stewart Dean. In the end there’s a lot to gain, both personally and financially. And you’ll learn a lot about yourself along the way.

Prototyping tools

Wondershare Mockitt review – Should this UI prototyping tool be on your list in 2021?

Late last year I received an invitation to try out and review Mockitt, a UI prototyping tool. I had never heard of it before, and judging from the eminent and annual UXTools survey, it wasn’t picked up by the masses either.


I have to admit I’m having a hard time keeping up with the latest tools. I stick with tried and tested industry standards, just enough up to date to fit in with most design teams I join as a contractor.


My personal experience aligns well with the UXTools survey when it comes to tools used for UI design and prototyping. To no-one’s surprise, Sketch, Figma, Invision and Adobe XD currently reign over the UI domain (at least in North America and Europe).


So where does Mockitt fit in in all this? I found a couple of reviews.

Tiffany Goh on Medium
Chuck Rice on Medium
Connection Cafe


It seems that Figma is the most commonly used benchmark when trying to understand where Mockitt fits into a designer’s workflow. Maybe that makes sense, I haven’t tried Figma’s prototyping capabilities enough to say. But in my mind, Mockitt is much closer to Axure than anything else I’ve seen.


Mockitt or Figma? I say Mockitt or Axure.


Maybe Axure has lost a bit of popularity in recent years, but it’s been a long standing favourite of the UX old guard in the UK. When it comes to building interactive prototypes it’s extremely powerful, without getting too bogged down in scripting and code.


From my initial mocking about (no pun intended), Mockitt doesn’t have the scripting possibilities of Axure, but it shares the same approach of states that Axure has built into its ‘Dynamic panel’ component.


Thanks to states you can create interactivity and dynamic pages. You don’t have to create new pages for every single interaction, as you would in Invision or Sketch for example. If you’re trying to do anything beyond simple click-through prototypes this is a godsend.

Axure in action.
Axure can easily get complex. Strict labelling of states and parameters is crucial.
Users coming from Axure will feel quite familiar in Mockitt’s work environment.


Mockitt is a prototyping tool


Just like some designers do wireframes and design in Axure, you can go from idea to prototype in Mockitt alone. The tool comes with drag and drop components from common UI frameworks like iOS and Android, so you could easily build a complete UI for mobile, desktop or other platforms. But it’s not a UI design tool like Sketch or Figma. As with Axure, you’re quite limited in making beautiful, bespoke UI elements from scratch. It’s not a tool for production design.


Will I use it?


For years, my workflow has been Sketch + Invision, or Axure, or sometimes even Sketch + Axure. Mockitt could replace Axure, but from what I’ve seen it falls short if I want to build a heavily dynamic and interactive prototype. Apologies if I’m wrong – I haven’t dug very deep in my analysis.


How does it compare in pricing?


Here’s the thing. I own a license of Axure RP 8. It was a one-off purchase. Axure RP 9 is a subscription service, and so is Mockitt. Annually $300 vs $69. If I were to subscribe to one of these today, the much cheaper price tag on Mockitt is compelling unless I severely need the unique features of Axure.


But for $144 a year you can get Figma, which offers both design and prototyping. If you need a tool for production design to complement your prototypes this would be a better option. Or you can buy a one-off Sketch license for $99 and use it with Invision for $156/year.

Figma offers a classic canvas environment that does both design and prototyping.
Invision in action.
Invision is the most limited tool in the list, but is extremely easy to use for simple prototypes.


There are of course other factors to take into account. Collaboration, version control, compatibility with other tools, plugins, dev handover etc. What’s right for you and your team will eventually come down to your unique needs and preference.


All these tools; Sketch, Figma, Axure, Invision and Mockitt offer free and trial versions, so the best thing to do if you’re looking for the optimal tools for your workflow is to give them all a go, using a real world project to stress test all scenarios.

figma.com
sketch.com
mockitt.wondershare.com
invisionapp.com
axure.com

UI designers, do you need to shift focus in 2021?

Various stimuli made me think about the topic of staying relevant. The key contributor, I think, is the constant reminder of how highly valued a glossy surface is. A slick and modern UI will get the votes in 2020 (instead of the insights and process that should proceed it). The problem is that anyone can design a slick and modern UI in 2021.

But first, some history.

Being a UI designer in 2001

The craft of UI design was hard in 2001. Most of the time it was a matter of applying usability and creativity (ever so stifled) to a medium that had limited styling options. It was a constant struggle of making the most of small screens with pixels large enough to detect on screen. To our help we had Photoshop, which wasn’t made for UI design but worked well enough to still be used to this day by some UI designers. And there was Flash, of course, for when you needed something more Flash-y so to speak. Flash was eventually abandoned as a development environment, but I still used it for prototyping from time to time simply because there wasn’t much else available.

Being a UI designer in 2011

Fast forward ten years, and things had gotten arguably even harder in 2011. By now, web and app front-end technologies had caught up. As designers we weren’t limited to basic web technologies for outputting our ideas. The evolution of web browsers, Javascript, CSS and webfonts all allowed us to mock up some serious design concepts and actually build it. If you saw an interesting layout in a printed magazine you knew you could replicate it, and add layers of transitions and interactions to boot.


With technology not holding you back any more, you had to become a better designer (restrictions are wonderful for problem solving, but you don’t push the envelope visually – and when someone does, you can easily tell whether they’re up to snuff or not). On top of that, the iPhone had given us a completely new paradigm of touch screen interactions to consider, and responsive web had just started to emerge. We had our hands full, but our design tools hadn’t evolved much other than updated versions of  Adobe CC and early versions of Axure and Sketch (I didn’t get introduced to Axure until 2013, and Sketch in 2014).

Being a UI designer in 2021

But in 2021, the craft of UI design is not hard. You still have to have the basic principles on point, but with so much inspirational content out there it’s every junior designer’s right and necessity to copy and steal until they have a good understanding of what works and what doesn’t (don’t get me wrong, this still takes years). UI design tools have exploded and long gone are the days when you had to Google tutorials for “how to make a gradient mask from 0 to 100 opacity”. We design with vectors and %. We have pre-sets and templates. We have tools built for purpose; for designing, prototyping and handing over.


UI design have had time to mature. Design systems and best practise guidelines have been refined over the years, and you can pretty much use a plug’n’play bootstrap UI or WordPress template and trust it will work (albeit not score any points for uniqueness, but who cares unless you’re a design agency pitching for work?).

A prediction that has been mentioned many times before

So where does that leave experienced senior designers and budding juniors alike? This is where my prediction comes in, which in fact has been told many times before.


GUI design, as in putting together graphical elements on a canvas to allow a user to accomplish goals, is becoming less and less of an artisan craft.

The steps from idea to wireframe to production UI are getting more and more automated. Anyone can download Figma and use a design library to put together the screen designs. The tools are intuitive to use and the design choices are built into the design system. You can have a perfectly fine ‘good enough’ solution and little is left for the UI designer to do.


The playing field is getting crammed with self-taught bedroom designers, ambitious product owners and even machines (close but no cigar). It’s time to find new ways to stay relevant and add value in the product development chain.

How to add value as a designer in 2021

Do you feel threatened by the competition? Have you noticed a trend of clients expecting more for less? If so, there are a number of ways you can hone your design profile to add value.

Go beyond ‘good enough’

Remember what I said about ‘good enough? Some clients appreciate the craft of GUI design, others think it’s just a matter of aesthetics and personal preference. Do yourself a favour and walk away from the latter. Find clients that understand the value of good design and offer them exactly that – thoughtful, bespoke, accessible, scaleable and on-brand. You need a stellar portfolio showcasing understanding of layout and typography, and a flair for motion and interaction design.

Branch into UI architecture

In my mind, all UI designers should have architecture skills. This is what makes them product designers rather than visual designers. Since our industry has decided to split skill sets into UI and UX, this is often not the case. Creating design hypotheses, defining user journeys and information architecture are tasks of a UI architect (some call them UX designers). If this can be done by the same person that creates the production UI, all the better. Less Chinese whispers and less overhead.

Become a UI developer

You already know how to design a pixel perfect UI, and you probably know about the technologies that will build it. Why not go back to school and learn how to use those technologies? To be able to design and build a UI to a high standard is still a very lucrative skillset and opens up doors to both high paid jobs, and the possibility to put any side hustle you can think of in motion. I thoroughly admire good designer/developers, and they are not common. You need to be aware of a boatload of tech in 2021 – but it can be done if your motivation is high. And most tools and knowledge are out there for free.

Get strategical

Strategy is evergreen. It will always be needed to gain the upper hand. In a previous post I separated product strategy into its own practise (user research, business requirements, product/market fit). I also defined design strategy as your approach to design – choosing the methods that help you choose a design track.

If you’re a design lead you can have massive impact on both efficiency and outcome with a solid design approach. This is then amplified by the number of designers adhering to it. Closely paired with design ops, design strategy becomes the conductor that orchestrates the design efforts into an integrated part in the larger product development machinery.

Become a design facilitator/manager

If you’re ready to step away from your hands-on role, you might want to become a facilitator or manager. These two roles are often performed by the same person i.e. the head of design or similar. But there’s a big difference in the two. A manager has direct reports and HR duties, for which you need a list of soft skills no one asked of you as a designer.


As a design facilitator your role is rather project managing on operational level. Your role is similar to the Agile scrum master. You remove hurdles and allow your colleagues to get on with work in the most efficient way. A facilitator defines the team’s design ops procedures. This means making sure that the team is properly integrated with the other teams, so that input and output is frictionless.

There will always be a place for slick and modern UI design. The issue some designers are going to face is the perceived value of it when it’s becoming more and more accessible. My recommendation for those designers is to make 2021 the year where they add skills that can’t be easily automated to their skill set.

Form fields illustration

Birthdate mobile form fields for iOS

In one of my recent project I’ve been designing the registration form for an iOS app. Form design is a classic UI challenge – One can spend a day designing a registration form, spend the rest of the week honing it, and the rest of the year optimising it once it’s live. Form design is notoriously known for being filled with pitfalls, and in mobile forms it gets even trickier.

A simple text input field isn’t much of a cumber, but the birth date input forced me to think carefully before settling on something. There are so many ways you can design this, and as Anthony is gracefully illustrating in this article on UX Movement, not all ways are equally good.

The challenge with birth date input is that you’re asking for three related numbers (month, date and year) and we want the user to quickly grasp what they need to do (enter birth date) in what format, and finally in what order (MM/DD/YYYY in my case).

You can get away with most solutions, especially with good error handling, but naturally I wanted to offer the most intuitive and quick solution that I could find. Inspired by Anthony’s article and after playing around with some ideas it came down to four options.

The DOB form fields shortlist

Native iOS date picker

Native iOS date picker UI.

Pros

  • Native iOS component means easy to implement
  • Error-safe. There is no way to enter incorrect formats
  • Quick: 6 interactions (I count a scroll as 2 interactions)

Cons

  • This solutions doesn’t translate to web, and need to be assessed separately in Android
  • Apples’s date barrel can be a bit fiddly, but at least by setting the default values to the middle values we can minimise the total scrolling across the user base (1971 is the median year, but in all honesty I didn’t check the median month and date – note to self; check that before launch).

Dropdown and number fields mix

Mixed input date of birth form fields.

Pros

  • Clear grouping and labelling of fields

Cons

  • Slow: Requires 9 interactions

Separate number fields

Separate input date of birth form fields

Pros

  • Clear grouping and labelling of fields
  • Can automatically jump to next field after two digits have been inserted

Cons

  • Medium Fast: Requires 8 interactions
  • Creates slightly more cognitive load converting birth month to a number instead of seeing the month in text

One number field

Single field DOB input UI.

Pros

  • This isn’t bad, but it has no pros against the other options listed.

Cons

  • Medium Fast: Requires 8 interactions
  • Creates more cognitive load figuring out the format

So which one did I choose?

Decisions, decisions. There simply is no perfect solution. As with most things design, we are problem solvers and solving a problem requires you to understand the context.

I went with the native iOS date picker. It’s easy to implement and quick to interact with (in theory), both of which work towards the success metrics for the project. This does mean that I will have to revisit this challenge when we do the Android and web apps, but at least that’ll give me a sort of A/B test against this solution and if the other solutions are performing better we can adopt that in the iOS app.

Have you any other good ways to enter birth dates? Let me know your thoughts.

Where in the design process are we? – Questions to ask yourself to pin down where you are and what to do next

‘Where are we?’ is not only one of my favourite tunes – It’s also a good question to ask ourselves when we join a new product development project.

You know that illustration of the design process as it really is; the one that turns a straight line into a tangled piece of yarn? It’s kinda like that when you step into a new project, trying to work out what the brief is really about and how you can best support the project goals.

Illustration of a messy design process.

It can be quite stressful knowing that it’s up to you to define the design plan but at the same time not be sure about the next steps.

Are the project success criteria clearly defined? Do you have validated and up-to-date user insights? Are there technical constraints you need to be aware of? Is the problem statement even the right one?

I find it useful to take my bearings by asking myself a set of questions when I join a new project. The answers can then help me pin down exactly where we are in the product life cycle and design process, thus informing me of next steps.

My design process – The double diamond

The double diamond has been embraced by the product design community wholeheartedly since it was introduced by the British Design Council in 2004. It wasn’t revolutionary, didn’t introduce anything new and designers had been using variants of it way before it was articulated in its current shape. But it gave us a name and a neat model that is easy to understand and tweak to our needs.

Double diamond design process

Using this ideal design process as a map for the project at hand, I can use the following set of questions and answers to understand where we are, and thus what we need to do next.

The design process is a model, obviously, and often far from what reality looks like. It may seem a bit too theoretical to be practical in the field but I have found it very useful to give structure to rather chaotic projects – over time it has become the lens I apply to any design brief I’m given.

Questions to ask at the beginning of your new design project

Is this a project? If not sure – Does the project have SMART goals?

Yes: Good, you’re off to the races.

No: The double diamond design process is not the right tool.

In order to put yourself on the process map, the very first thing we need to establish is that you’re part of a project. The double diamond design process is project-led, so if you’re joining a team tasked with maintaining a design system or run designOps, that’s going to require a different process. This is probably quite easy to detect, but if ever in doubt wether this is actually a project, simply map your duties against SMART objectives and if it doesn’t add up your work isn’t project-led.

Do we know what problem we’re solving (or opportunity we’re chasing)?

Yes: At least you’re not in the 1st quarter of the design  process.

No: You are at the very beginning of the process and need to create a problem statement or project objective.

In my double diamond the first diamond refers to product/market fit. Others simply define it as the discovery or research phase. Either way, the first diamond is about answering the WHAT, and the second diamond is about the HOW. That’s a great clue right there and I use it all the time if I’m unsure.

If your brief is “Design this app that is like Tinder for dog owners” you can pretty much rip off Tinder and have a pretty nice design done in a short time. But if the answer was ‘no’ to the question above, you know there’s work to be done in the WHAT diamond.

This is not always what the client wants to hear, but challenging the brief and pushing for a solid product/market discovery phase is sometimes needed and will help the project in the long run. Of course, the client pays your bills so know when to stop being an idealist and find a compromise if needed.

Do we (really) know who we are designing for?

Yes: You can start exploring solutions in the HOW diamond.

No: You are in the 1st or 2nd quarter of the design process and should gather or synthesise user insights.

In our dog owner Tinder example you would’ve been excused for thinking it’s a shit idea. But maybe the product owner hands you some convincing market trends that points towards a real opportunity.

If we don’t know what the USP is (or wether our users actually value that USP), or don’t have a better persona than ‘Dani the dog owner’, you have some user research ahead of you. A design decision should always be a response to a verified hypothesis about your users. This is called hypothesis-driven design and it’s the bee’s knees.

Do we trust the accuracy of the user insights provided?

Yes: You can start exploring solutions in the HOW diamond.

No: You can either redo the user research in the WHAT diamond, or do a mini discovery before you enter the HOW diamond.

Quite often I find myself brought into a project at the beginning of the HOW diamond, only to find that the user and market insights given to me aren’t up to snuff. What was handed to you as a set of personas might’ve been user profiles based on the stakeholders assumptions of the user. What was claimed to be user behaviour based on usage data might not be applicable if you’re entering a new market with the new design.

In this case it’s highly unlikely that you’ll get the time and budget to redo the research phase, but you should at least highlight the issue with missing or false insights and decide best way forward together with your team.

Are all relevant hypotheses about your users answered?

Yes: You can start exploring solutions in the HOW diamond.

No: You can either redo the user research in the WHAT diamond, or do a mini discovery before you enter the HOW diamond.

Similarly to the question above, you might find that after doing a hypotheses exercise you don’t have the answers to design-critical assumptions. Spend some time filling the gaps best you can before going into solution exploration. This doesn’t have to directly include users if that’s too much of an ask. You can also go through customer feedback logs, look at analytics data and talk to stakeholders and subject-matter experts.

Do we know how we are solving the problem (or realising the opportunity)?

Yes: You’re in the final quarter of the design process, with focus on production and testing.

No: As long as you know what and for whom, you’re ready to explore options.

This far into the process it’s usually easy enough to know what’s going on and what needs to get done. Blockers and friction here is more likely related to the designOps in place; i.e. your tools and processes for producing, testing, signing off and handing over design.

A good process is paramount for efficient product development. Unfortunately, humans are a messy bunch. When we are put together in large companies with layers of sub-cultures within, we often get a cocktail of conflicting interests, ideas and values pulling the project in all directions.

This is probably why I’m often overwhelmed in my first days in a new large scale project. Things aren’t always straight forward, and we simply have to make the best of the situation and find a way of working that contributes most towards the end goal.

Stay calm, ask questions and figure out what needs to get done. I believe that’s a good way to keep your client happy and your stress levels down.

What is UX strategy? An attempt to decipher something that shouldn’t need deciphering

If you ask a UX professional what UX strategy is, you’d get answers as widely spread as hippo poo, of which the majority would be vague. Why? Because strategy is a confusing catch-all phrase, but still we want to include it in our skill set. Because it’s expected of us:

In any project in which you work as a UX designer, it is fundamental to start by drafting a solid strategy.

Jerome Kalumbu

I’m guilty of this; calling myself a design strategist but secretly hoping no one would call me out on it. If someone did, I would probably say something about defining the right approach for the target audience. That isn’t wrong per se, but what was missing was a clear definition of strategy, and the methodology to execute it.

To redeem myself I picked up one of the top-rated books on strategy and started to educate myself. Actually, the very first thing I did was to google ‘UX strategy’ but what I found was more confusing than helpful since everyone got their own take on it. Some say it’s a business strategy, others call it a plan, and if you look somewhere else it’s an alignment of the product vision with its users.

I don’t mean to bash these definitions in any way – in their own context they make perfect sense. But with so many answers out there, the only thing I could do to truly own the topic was to dissect it and shape my own opinion. So, based on the definition of strategy in the book Good strategy Bad strategy by Richard P. Rumelt, I did my best to really understand how I can use strategy in product design without the risk of losing face.

Strategy is a 3-step process

‘Strategy’ is a bit like ‘UX’; it gets thrown around a lot without much thought of what it actually means. Good strategy requires hard work, but strategy on a theoretical level isn’t difficult – it will sound all too familiar to anyone with experience in product design. Because, without knowing it, we’ve been doing strategy all the time. This is how strategy is defined in Good strategy Bad strategy:

  1. Diagnose the situation to understand what’s going on.
  2. Choose the overarching approach that will provide the most leverage.
  3. Define coherent actions that executes the approach.

Sounds familiar? This is pretty much textbook any design process I’ve come across. [Discover – Design – Deliver], Design Thinking, Lean UX, Design sprints, Double Diamond… they all have these basic steps embedded in the process.

The conclusion: Our design process is strategy in itself.

Let’s go back to our definition of strategy and relabel it:

  1. Define a problem space and gather insights to understand it.
  2. Explore possible approaches to solve the problem, and based on the insights, pick the one most likely to achieve desired results.
  3. Come up with a design plan with all the actions needed to execute the approach until measurable results have been achieved.

Admittedly, step two is where the real ’strategy’ work comes in, but Rumelt is quick to mention that step two is not enough to define a good strategy. Just as I mentioned in this article, the beginning and the end are the two most important steps of any project – we need step one and three in order to define and execute step two, aka ’the strategy’.

How to think about strategy as a product designer

For sure we can talk about UX strategy, but just like an ill-defined design process it will bring little to no value to the project. If we want to talk about strategy in a product design setting we need to break it down into smaller parts.

Using the Double Diamond product design process I propose thinking about UX strategy in two steps; Product strategy and Design strategy. Hear me out though, this is not only word-smithery. It’s my attempt to break something too complex into something usable.

Double diamond design process with an overlay of UX, product and design strategy.

UX strategy = The complete design process.

This seems to be aligned with the definition outlined in the book UX Strategy: How to Devise Innovative Digital Products that People Want by Jamie Levy:

UX strategy is […] being able to research what’s out there, analyze the opportunities, run structured experiments, fail learn and iterate until you devise something of value that people truly want.

Product strategy = The first diamond (What are we doing?), where the strategy part is choosing what to focus on to reach product/market fit.

Out of all steps, this is by far the hardest to get right. If there is a secret sauce to UX strategy, this is where you’ll need it. Considering how many established companies that become obsolete, and startups that pivot time after time, it’s clear that this is more gambling than science – the key is to better your odds with step one.

Design strategy = The second diamond (How are we doing it?), where the strategy part is your approach to design.

This will probably be a combination of tried and tested ways of working: Lean UX, Mobile first, Atomic design etc. Doesn’t sound very strategic, does it? But imagine designing without these approaches in place and you can see where the value of design strategy comes in.

Step two and three in the design strategy actually come before step one and should be fairly rigid from project to project. Design strategy is not about choosing the correct design – it’s about choosing the methods that help you choose and efficiently execute the correct design.

Let’s look at a practical example.

Case study: The UX strategy of a startup

Söber is a company offering chauffeurs to intoxicated people who need to get themselves and their car back home safely.

By exploring the opportunity space, they’ve found a market in mid-sized towns with poor public transport and no competition from online cab companies. Furthermore they know that the most receptive target groups are couples and groups of girlfriends dining out in the weekend.

Based on these insights, the approach for going live and testing their product/market fit is to launch a trial in a region with three mid-sized towns close to each other. This way they can recruit drivers that can serve all three towns. Rather than doing the heavy up-front work of an in-house infrastructure, third-party solutions and manual work will be used during the trial.

On the end-user side, the approach is to make an app available for download on Apple’s Appstore – a decision based on the target groups’ phone preference and the fact that the service needs to be accessible on the go and utilise positioning technology. Both target groups will be included in the app design and marketing efforts as the benefit of a larger user base is deemed greater than the additional cost of targeting two separate segments.

The plan to execute this approach includes recruiting the drivers, marketing the service, integrating a customer-driver matching backend, and building the consumer facing app.

As you can see, the product strategy branches out into different tracks, of which the consumer-facing app is one. Let’s take a look at that one.

From the product strategy, the product design team of Söber has the commercial and technical requirements to understand what the app needs to do.

Step one in the 2nd diamond seeks to understand and explore the challenge in a user-centric way. If there are enough insights gathered already, the team could move on to explore various directions the app could take. In Söber’s case, the app isn’t yet specified down to the specific features, and the team needs to do another iteration of the 1st diamond. They do this to form and validate hypotheses around the use of the app.

Do couples bring their children, meaning they’ll need an option for child seats?

Would a group of women feel more comfortable if they could choose a female driver?

Is cost-splitting essential for the app’s success?

Once the team has a good grasp of the value proposition and key user journeys, they can move into exploring design options. As they are integrated with an agile development team, they do this feature by feature, delivered in sprints and user tested before build.

To conclude

Reading Good strategy Bad strategy and writing this article has helped me ironing out a lot of the kinks in my understanding of strategy and how it is applied to product design. Although good strategy is needed in every project, talking about strategy in any form is a bit like talking about UX – a term so inflated that it has almost lost its value.

As designers we should remember that our end-to-end design process is strategy work in action. We can almost always replace ‘strategy’ with ‘approach’ to demystify our design documentation and presentations. Likewise, there’s nothing wrong with asking someone to clarify what they mean with strategy if you see it in their material.

Hopefully reading this has been informative rather than adding more confusion to the matter. Everyone has to shape their own understanding of the world, and I’m not here to say I’m speaking the Truth – But it is my take on it. For now.