It occurred to me that so far I barely touched the UX and UI aspects of the product management world.

I think it’s time to fix that… don’t you think? 🙂

Maybe it’s worth setting some expectations first – this post is not going to focus on the latest design trends and how to apply them. There are better experts on this out there who probably wrote dozens of posts about this already. Instead, as always, I’m going to outline a practical approach on how you should work with a professional designer to get the best outcome for your product.

 

But – first things first – just to make sure we’re on the same page:

The difference between UX and UI

UI (user interface) is about the look & feel of the graphical elements which are drawn on the screen. It’s more tuned towards eye candy, and investing in the UI of your app/platform/product means it will probably look more professional.

UX (user experience), on the other hand, is about the interactions and the flows of the UI. For example – what the user needs to do (in terms of interactions with the UI) in order to execute a specific flow or how the navigation on your site is going to behave like. Investing in the UX of your product means the interactions are going to be much more intuitive to the user and that the various flows can be executed much more efficiently.

 

The main designer roles out there

As a product manager you’ll probably need to ‘spec-out’ some product specifications that include UX and UI elements from time to time – unless you’re managing a product which is 100% backend in nature (for example – a recommendation engine). But even if your product has no user interface – it’d be good to understand the various concepts because most likely – as you progress in your career – eventually you’ll own products which have a user interface.

In such scenarios – you’ll need to work with a UX/UI designer in order to deliver a professional spec (PRD) to your engineering team.

Now, it may be very likely that your team or company doesn’t have an internal UX/UI designer, and you are employing a freelancer for that. Nevertheless – the principles are the same.

First – let’s distinguish between the most 3 common designer roles you may need to interact with:

1. UI experts
2. UX experts
3. Product designers

UI experts

UI experts are people who are great at drawing graphical elements. It could be buttons, check-lists, navigation bars, logos or anything which requires pixel-perfect drawings. They may or may not possess UX knowledge, and if they possess it – it may be quite basic.

UX experts

As you can already imagine – UX experts are the exact opposite. They don’t necessarily excel at drawing UI elements, but they are definitely good at designing screens and flows that make sense and are quite intuitive.

Product designers

Product designers have decent knowledge of both UX and UI. They may be expert in none, but they may be exactly what you need for your product in case the user interface of your product is not ‘the main thing’ and only required for controlling the ‘real’ product underneath the surface.

 

Of course – reality is more complex than these stereotype definitions. You may come across super talented people who are strong in both UX and UI, and you may come across designers who are very good at only one dimension – regardless of the official title they carry. It’s exactly the same as with any other profession really (product management included). Not everyone excels in more than one aspect of their job.

 

How should I choose the designer I work with?

This question implies a freedom of choice, which in many cases is simply not aligned with reality. Let me explain.

Depending on your company’s size and structure – there are several options as for how the designers are managed as ‘resources’.

There may be a dedicated designers group that you can pull a resource from based on your needs, or you may have a designer assigned to your group already. Some companies have neither, and prefer to outsource these tasks to outside contractors. It usually happens when the line of products of the company doesn’t involve tons of user interface, or it’s not the main thing.

Thus, in some cases, such as when your company has a ‘guild’ of in-house designers, you can look for a specific expertise based on the feature/product you’re working on. The downside here is that you may have to wait a sprint or two before the person will be available to you.

In the other cases you’ll probably have an immediate access to the person, but much less choices to choose from, either because you must work with the resource assigned to you, or you must work within some budget constraints with outside contractors.

The best, IMHO, would be to have a dedicated designer in your team, where you were an integral part of the hiring process and this is the person you pushed for hiring. That would be the best, but again – sometimes it’s not up to you.

If you have several choices and not sure how to choose then I’d suggest the following simple decision scheme:

1. If your product is B2B, or even if your company is B2B2C, but your product is aimed for the ‘B’ (your real customer) and not the ‘C’ (the end user) – then I’d definitely favor UX expertise over UI. From my personal experience (and some of you may disagree) – business users tend to favor efficient flows for executing actions or getting the data they want, over a cumbersome system which looks great. I’ve seen some really bad-looking systems in my life with very happy users, because the users were able to make the system do what they wanted and with a very little effort.
2. If your product is B2C, or your company is B2B2C and your product is aiming for the end users (the consumers) – then suddenly the UI becomes much more important. I’d still argue that UX is more important (because an intuitive user interface is crucial for the consumers as well, who will only give your product one chance). However, the UI can no longer be neglected. Hence – you’ll need both. Probably a good product designer.

How should I collaborate with my designers?

The way you collaborate with your designers is highly dependent on the scope of the feature. If it’s a small feature that requires some UX and UI tweaks – that’s one thing. However, if you’re working on a big feature or a new product – then the interaction becomes more involved.

What’s common to both cases is the iterative nature of the process. Whether it’s wireframes or real screens – you will probably iterate with the designers until you are both happy with the result. That’s a bit different from how you interact with the engineering team or the data analysts, for example.

 

When you are working on a modest feature for an existing product

Assuming your feature requires some UI and UX work (it’s quite rare to have a feature which requires only one of those) then I’d work according to this sequence:

1. Write the spec, while totally ignoring the UX and the UI of the feature. Focus on the ‘why’ and where the value is. Or, in other words, work according to my post on how to write awesome specs (here).
2. Once the ‘why’ and the ‘what’ (minus the user interface) are ready – confirm the overall solution with the internal stakeholder who asked for it (if you received the ask indirectly from a customer through support, CS or sales). If you heard it directly from the customer – simply proceed to the next step.
3. Send the spec to the designer who is going to work with you on this feature. Have a short conversation with them about the spec, and make sure they understand what you’re trying to accomplish here. Ask them to come up with a wireframe (for big features) or an actual design, which need not be pixel perfect (for smaller features). 
4. Review their work and iterate with them until you both feel it’s good enough to be tested with real customers/users. In case you have a decent A/B testing infrastructure – consider producing several variants that can be tested using the infrastructure.
5. Once you both feel comfortable about it – complete your spec by linking the design in the right chapter and proceed to a spec review.

 

There is nothing really innovative in the process I’ve outlined above. Yet, some product managers tend to work according to a different order, where they start with the design.

I think it’s wrong. You should never start with the design. As I always say – your journey must start with the ‘why’. Why are you working on this feature and where is the value? 

I am fine with involving the designer a bit earlier when working on the ‘what’ (the user stories and functional requirements), but only for getting the overall opinion as for how the flow should look like.

If you start with the design you truly risk missing delivering the value you want to your users/customers, because you may ‘bend’ the requirements to cater to the design (instead of the other way around).

 

When you are working on a big feature or a new product

This is where things are getting more interesting. It’s also where the designers can really shine.

A big feature can be:

• Rewriting an important component (such as a dashboard for example)
• Adding a totally new key functionality to your product (for example – start offering a ‘self service’ to a product which was only sold via sales people before).

A new product can practically be anything. For example – your company is a financial crypto trading company deciding to expand into a new market by offering ‘crypto loans’.

If you are the product manager leading such initiatives then you are lucky – because this is very exciting.

That being said, your designer is going to play a much bigger role than before, so it’s crucial to choose the right person. Your day-2-day designer may not be up to the task, so don’t assume he/she is going to be your partner.

When approaching such projects you are usually given a blank canvas and a vision – and you need to progress from there. Let’s try to break it down to steps, though reality, again, may shuffle some of the steps mentioned below.

 

The ‘Why’ and the discovery process

My best advice for the first step is again to start with the ‘why’ – but this time ask yourself why your company (or you) believes it’s important to work on this huge initiative now. Or, in other words – start with the underlying assumptions as to why it’s needed and why now is the right time to work on it.

There is probably a long discovery process that needs to be involved here. Sometimes this process has already taken place prior to making the decision to go for this project, and it was the one supporting it. If it wasn’t performed before then now would be the time to do it. The discovery process deserves a post of its own, so I’ll just say two things about it:

1. The goal of this process is to validate the underlying assumptions as much as you can, without building an MVP. That includes also validation of the market opportunity, market size and the underserved pains of the potential users/customers. An MVP will probably come later on, but it will be a bit later in the process.
2. The designated designer you are going to work with on this project may ask to join you in this process, and sometimes even to lead it. I definitely recommend making them part of the process if they want, but I wouldn’t recommend letting them lead this process. I truly believe a product manager is the one to lead such processes, since a product is much more than the user interface associated with it.

The use cases

Once the discovery process is completed and the assumptions still seem to be valid – the next step is to proceed to the use cases. What are the use cases this product/feature needs to support. List them all and be very clear about what can be accomplished with each, and by whom. For example – in the ‘loans’ example above, some of the use cases would be:

• An existing crypto user will be able to sign up for a loan if some pre-conditions are met.
• A user who took a loan will be able to view their payment schedule and where they stand with this schedule.
• An account manager will be able to view all users who took a loan in their region, and their current status
• Etc…

MVP – yes or no

Now you have two options depending on the circumstances – if you believe this big feature or product is relying on assumptions that still require validation – then you’ll need to proceed for an MVP.

If you are just rewriting a module that existed before, or you believe your discovery process provided you with enough confidence regarding the assumptions behind the product – then you can skip the MVP.

In this post I won’t explore the MVP venue, as it’s an art of its own, so let’s assume that an MVP is unneeded.

Drilling down to the use cases

So, at this point we have a list of use cases. A good designer will ask you to break all the use cases into steps or actions. For example – when taking a loan – what are the needed steps in order to complete the flow? When the account manager views a user’s status – what type of data they would like to see?

A good designer will ask plenty of questions, and probably force you to go back and revisit your list more than once. This is an iterative process that will take some to exhaust.

The designer may also challenge the personas analysis you’ve done and claim it’s incomplete (or simply lacking) and requires additional work. That’s fine. Work with them on the personas analysis, but do put a stop on this when you believe it’s good enough (as I observed, sometimes product managers and/or designers are getting too deep into such analysis, beyond the point of any additional positive ROI).

Note that so far – nothing is drawn yet. That’s totally fine.

One of the main outcomes of this process are the user flows, but from a product perspective. Meaning – the list of use cases mentioned above + the various steps that are needed to be performed in order to accomplish the use case.

The wireframes + spec

Now it’s the time to hand over the ball to the designer. It’s their time to shine.

Next stop – wireframes for all the screens and user flows.

And while your designer is working on the wireframes, you need to use this time to start working on the spec (PRD).

As the work on the wireframes is progressing, the designer will come back to you with tons of questions. Their questions will force you to put some thoughts on flows and interactions that you’ve missed, so that’s a good thing. Therefore, you can’t really hope to finalize the spec before this step is concluded.

You will probably iterate with the designer on the wireframes until you both feel the UX is intuitive & efficient enough.

Once the wireframes are starting to get into shape I recommend getting initial feedback from all the relevant internal stakeholders including the engineering.

Finalizing the user interface and the spec

Once you process and apply all feedback it’s time to work on the UI (from the designer’s perspective) and finalize the spec (from your perspective). It can, and it should, be done concurrently.

Once everything is completed – you can proceed with the delivery process as usual (spec review, engineering design, implementation, QA and production).

And… iterate based on users or customers feedback 🙂

 

To summarize

Any feature or product that you work on and involves user interface changes requires a designer if you want the result to look & feel professional.

Your designer, however, shouldn’t be your first stop. As always start with the ‘why’ like any other feature. Usually the UX/UI better be addressed after the data model is finalized, so you might even want to make some progress on the user stories and functional requirements before starting to work with the designer.

Last – not all designers can tackle effectively both UI and UX tasks. Pay attention to their speciality and find a way to close the gap if you find one (by adding hiring another designer, outsourcing it or something else). 

 

That’s it for today!

If you found this post/series useful – please let me know in the comments. If you think others can benefit from it – feel free to share it with them.

 

Thank you, and until next time 🙂