Being a Product Owner is a lot of work, especially during project scopes. You'll have to attend regular meetings, answer tricky questions and make hard choices. As the Product Owner, the shape of the application is truly in your hands. Designers and developers will guide you through the process but ultimately it's your decision what ends up in your application. The blogs I have written in the past have been geared towards empowering Product Owners with an understanding of what goes on in a designer's brain.

This is so that you, as a Product Owner, are better able to navigate the exciting scoping journey and appreciate the value of the many activities you will be involved in. Our hope as designers is that these activities will open communication channels and result in a very good understanding of what the vision for the application is, along with the technical and budgetary constraints.

From time to time, however, things go a little off-track. Sometimes it is because a Product Owner's expectations don't align with the brief – and sometimes, it's because the designer themselves just doesn't 'get it'. In this blog, I'm going to give you, the Product Owner, insight into ways you can rescue a situation like that and help your designer truly realise the goal.

So, why do designers sometimes miss the point?

Let's be real about this: software design isn't easy. As much as Product Owners have to work hard to answer questions with as much rich detail as possible, it's up to the Product Designer to ask the right questions in the first place. Even after we've received an answer, we still have to translate all that information into a slick user experience and interface that matches the client's time and budget.

As a Product Owner, if you feel that your designer doesn't seem to understand the purpose of your application, it's probably because somewhere along the way the waters have been muddied. Shifting goalposts and technical curveballs might have been inevitable bumps on the road, but can also contribute to major misunderstandings between you and your designer. When those things happen, rather than pointing fingers, here are some simple things you can do to keep it moving.

1. Return to the initial problem

During the Brief stage, you will have likely come up with a problem statement. Usually, they go a little something like this:

“How do we create a user-friendly mobile platform which will allow retirees to easily access mental health resources?”

At WorkingMouse, we make use of problem statements alongside a Lean UX canvas to identify target users, frequency of use and business goals. Even if you're not developing with WorkingMouse, you probably have a list of business and user goals for your product (and if you don't have this list, you need to get one!). When things go awry during scoping it is often because the conversation has shifted away from the initial vision to something else. In ideal circumstances, this shift represents a wicked problem being untangled and transforming into viable product ideas. In other cases, a pivot can result in more confusion, not less. When that has happened, it's important to return to the core problem that you want to solve in the first place. Ask yourself:

• Is this really the problem I want to solve?
• Are these the users who are most affected by this problem?
• Do my business goals reflect what I really want as a Product Owner?

Now, think back on the artefacts and discussions you have shared with your designer. Is the recent work coming out of scope representative of the three questions above? If not, then it's time to return to the Lean UX canvas - the initial goals. In these cases, I recommend performing the user flow and personas activity with your designer so you can properly map out the ideal journey for your future users.

2. Be specific

This one is very important: as a Product Owner, your feedback is critical to us designers. Comments such as 'I don't like it', or, 'Can you add more pop?' are vague, subjective and quite unhelpful. Every designer dreads hearing the following: 'I don't know what I want, but I'll know when I see it'. If your designer is consistently coming up with designs or ideas that just don't appeal to you, then you will have to get specific with your feedback so they know what you want.

The other side of this is that your feedback should be concrete and not change on the hour, every hour. Consider this situation: a client tells their designer that they are looking to create a simple UI that is corporate and professional. The next day, the client realises that the corporate look doesn't suit their brand, and tells the designer that instead they're looking for something peppy, bright and heavily illustrated. Upon seeing the concepts, the client then decides that the highly ornamented look doesn't work for their user base and wants to return back to the original, corporate style.

This pendulum of design feedback is tricky for designers to manage but ultimately the cost is to you, as a product owner. Remember: you are paying for the designer's time. Do you want them to spend their time creating endless concepts or to actually deliver a prototype that will translate into the app you want?

In our experience, when a client changes their mind frequently during scope, it is simply because there is a lack of confidence in the decisions being made.

If you find that you are changing your mind often during scope, perhaps consider that the issue is not the work being presented, but the fear that the decision you have made isn't the 'right' choice. In agile methodology, making a 'wrong' decision is simply a learning process. You might believe your users like things a certain way, and then learn during testing that the opposite is true.

3. Show some examples

Good references are crucial for design and art in general, and are handy for you when it comes to demonstrating the things that inform your vision. Designs, illustrations, animations and interactions are all useful artefacts to present to a designer when you want to get a point across. There are numerous ways you can go about doing this, but we have found that mood boards or simple reference lists are sufficient in showing concrete examples of work that you like. Your designer will probably ask you questions such as:

• 'What is it about this specific design that appeals to you?
• Why does it appeal to you?
• What about this design don't you like?
• Would this design appeal to your target users? Why/why not?

While it's important not to rip-off other people's work, the truth is that there are commonalities between successful works no matter the medium. Identify the things that appeal to you and work with your designer to make them truly unique.

4. Remember that you are not your users

During scoping, designers, developers and Product Owners naturally dominate the discussion because, well, they're the only ones in the room. That is why at WorkingMouse we try to incorporate as much user testing and feedback as we can. The truth is that the target users may not be the same people as the ones building the application. Naturally, then, this will mean that design decisions are carried out that may not necessarily appeal to you as an individual but are likely to resonate with your target audience.

The challenge for you and the designer is to find that happy medium where the design speaks to the right demographics but pleases you as a Product Owner as well. This philosophy doesn't just end at design, but extends to the functionality of the app as well. The personas activity is recommended in such circumstances. Every time a design or technical decision is made, you can refer back to the personas to determine whether the change is relevant to your target users.

Our Guide to Creating a Successful Software Product will aid you in these decision-making stages, which you can download for free below.

Another useful activity for determining the worth of a design or functionality feature is prioritisation. Recognising that each piece of your application has a time (and therefore material) cost helps to make critical decisions about what ends up in your software. Alongside your trusted personas document, you will be better positioned to determine what features are actually going to benefit your valued users.

5. Things can change

Don't panic if the design of your application doesn't quite live up to your expectations right away. Design, like development, is an iterative process and it's quite normal for the UI and UX to go through several versions. Even during development itself, aspects of the design may change or update. This is nothing to be alarmed about but is instead a natural part of the design process. In fact, your brand and application design should be continuously evolving.

Here are some final tips to keep in mind once you start scoping and developing:

• A design system or brand can help steer your product on the right track. If you don't have one, we can work with you to develop it.
• Read up on UI design and how it differs from traditional print or even digital design
• Don't be afraid to ask questions.
• Understand that every iteration of your application or brand is an opportunity to collect feedback.
• And if all else fails, feel free to seek a second opinion. Gather feedback from an inhouse or 3rd-party designer to get their own insights.

If you're prepared to transform your business with the help of software, contact us here.