5 Things to Do When Your UX Designer Doesn’t Understand What You Want


Being a Product Owner is a lot of work, es­pe­cially dur­ing pro­ject scopes. You’ll have to at­tend reg­u­lar meet­ings, an­swer tricky ques­tions and make hard choices. As the Product Owner, the shape of the ap­pli­ca­tion is truly in your hands. Designers and de­vel­op­ers will guide you through the process but ul­ti­mately it’s your de­ci­sion what ends up in your ap­pli­ca­tion. The blogs I have writ­ten in the past have been geared to­wards em­pow­er­ing Product Owners with an un­der­stand­ing of what goes on in a de­sign­er’s brain.

This is so that you, as a Product Owner, are bet­ter able to nav­i­gate the ex­cit­ing scop­ing jour­ney and ap­pre­ci­ate the value of the many ac­tiv­i­ties you will be in­volved in. Our hope as de­sign­ers is that these ac­tiv­i­ties will open com­mu­ni­ca­tion chan­nels and re­sult in a very good un­der­stand­ing of what the vi­sion for the ap­pli­ca­tion is, along with the tech­ni­cal and bud­getary con­straints.

From time to time, how­ever, things go a lit­tle off-track. Sometimes it is be­cause a Product Owner’s ex­pec­ta­tions don’t align with the brief — and some­times, it’s be­cause the de­signer them­selves just does­n’t ‘get it’. In this blog, I’m go­ing to give you, the Product Owner, in­sight into ways you can res­cue a sit­u­a­tion like that and help your de­signer truly re­alise the goal.

So, why do de­sign­ers some­times miss the point?

Let’s be real about this: soft­ware de­sign is­n’t easy. As much as Product Owners have to work hard to an­swer ques­tions with as much rich de­tail as pos­si­ble, it’s up to the Product Designer to ask the right ques­tions in the first place. Even af­ter we’ve re­ceived an an­swer, we still have to trans­late all that in­for­ma­tion into a slick user ex­pe­ri­ence and in­ter­face that matches the clien­t’s time and bud­get.

As a Product Owner, if you feel that your de­signer does­n’t seem to un­der­stand the pur­pose of your ap­pli­ca­tion, it’s prob­a­bly be­cause some­where along the way the wa­ters have been mud­died. Shifting goal­posts and tech­ni­cal curve­balls might have been in­evitable bumps on the road, but can also con­tribute to ma­jor mis­un­der­stand­ings be­tween you and your de­signer. When those things hap­pen, rather than point­ing fin­gers, here are some sim­ple things you can do to keep it mov­ing.

1. Return to the ini­tial prob­lem

During the Brief stage, you will have likely come up with a prob­lem state­ment. Usually, they go a lit­tle some­thing like this:

“How do we cre­ate a user-friendly mo­bile plat­form which will al­low re­tirees to eas­ily ac­cess men­tal health re­sources?”

At WorkingMouse, we make use of prob­lem state­ments along­side a Lean UX can­vas to iden­tify tar­get users, fre­quency of use and busi­ness goals. Even if you’re not de­vel­op­ing with WorkingMouse, you prob­a­bly have a list of busi­ness and user goals for your prod­uct (and if you don’t have this list, you need to get one!). When things go awry dur­ing scop­ing it is of­ten be­cause the con­ver­sa­tion has shifted away from the ini­tial vi­sion to some­thing else. In ideal cir­cum­stances, this shift rep­re­sents a wicked prob­lem be­ing un­tan­gled and trans­form­ing into vi­able prod­uct ideas. In other cases, a pivot can re­sult in more con­fu­sion, not less. When that has hap­pened, it’s im­por­tant to re­turn to the core prob­lem that you want to solve in the first place. Ask your­self:

  • Is this re­ally the prob­lem I want to solve?
  • Are these the users who are most af­fected by this prob­lem?
  • Do my busi­ness goals re­flect what I re­ally want as a Product Owner?

Now, think back on the arte­facts and dis­cus­sions you have shared with your de­signer. Is the re­cent work com­ing out of scope rep­re­sen­ta­tive of the three ques­tions above? If not, then it’s time to re­turn to the Lean UX can­vas - the ini­tial goals. In these cases, I rec­om­mend per­form­ing the user flow and per­sonas ac­tiv­ity with your de­signer so you can prop­erly map out the ideal jour­ney for your fu­ture users.

2. Be spe­cific

This one is very im­por­tant: as a Product Owner, your feed­back is crit­i­cal to us de­sign­ers. Comments such as ‘I don’t like it’, or, ‘Can you add more pop?’ are vague, sub­jec­tive and quite un­help­ful. Every de­signer dreads hear­ing the fol­low­ing: ‘I don’t know what I want, but I’ll know when I see it’. If your de­signer is con­sis­tently com­ing up with de­signs or ideas that just don’t ap­peal to you, then you will have to get spe­cific with your feed­back so they know what you want.

The other side of this is that your feed­back should be con­crete and not change on the hour, every hour. Consider this sit­u­a­tion: a client tells their de­signer that they are look­ing to cre­ate a sim­ple UI that is cor­po­rate and pro­fes­sional. The next day, the client re­alises that the cor­po­rate look does­n’t suit their brand, and tells the de­signer that in­stead they’re look­ing for some­thing peppy, bright and heav­ily il­lus­trated. Upon see­ing the con­cepts, the client then de­cides that the highly or­na­mented look does­n’t work for their user base and wants to re­turn back to the orig­i­nal, cor­po­rate style.

This pen­du­lum of de­sign feed­back is tricky for de­sign­ers to man­age but ul­ti­mately the cost is to you, as a prod­uct owner. Remember: you are pay­ing for the de­sign­er’s time. Do you want them to spend their time cre­at­ing end­less con­cepts or to ac­tu­ally de­liver a pro­to­type that will trans­late into the app you want?

In our ex­pe­ri­ence, when a client changes their mind fre­quently dur­ing scope, it is sim­ply be­cause there is a lack of con­fi­dence in the de­ci­sions be­ing made.

If you find that you are chang­ing your mind of­ten dur­ing scope, per­haps con­sider that the is­sue is not the work be­ing pre­sented, but the fear that the de­ci­sion you have made is­n’t the ‘right’ choice. In ag­ile method­ol­ogy, mak­ing a ‘wrong’ de­ci­sion is sim­ply a learn­ing process. You might be­lieve your users like things a cer­tain way, and then learn dur­ing test­ing that the op­po­site is true.

3. Show some ex­am­ples

Good ref­er­ences are cru­cial for de­sign and art in gen­eral, and are handy for you when it comes to demon­strat­ing the things that in­form your vi­sion. Designs, il­lus­tra­tions, an­i­ma­tions and in­ter­ac­tions are all use­ful arte­facts to pre­sent to a de­signer when you want to get a point across. There are nu­mer­ous ways you can go about do­ing this, but we have found that mood boards or sim­ple ref­er­ence lists are suf­fi­cient in show­ing con­crete ex­am­ples of work that you like. Your de­signer will prob­a­bly ask you ques­tions such as:

  • ’What is it about this spe­cific de­sign that ap­peals to you?
  • Why does it ap­peal to you?
  • What about this de­sign don’t you like?
  • Would this de­sign ap­peal to your tar­get users? Why/why not?

While it’s im­por­tant not to rip-off other peo­ple’s work, the truth is that there are com­mon­al­i­ties be­tween suc­cess­ful works no mat­ter the medium. Identify the things that ap­peal to you and work with your de­signer to make them truly unique.

4. Remember that you are not your users

During scop­ing, de­sign­ers, de­vel­op­ers and Product Owners nat­u­rally dom­i­nate the dis­cus­sion be­cause, well, they’re the only ones in the room. That is why at WorkingMouse we try to in­cor­po­rate as much user test­ing and feed­back as we can. The truth is that the tar­get users may not be the same peo­ple as the ones build­ing the ap­pli­ca­tion. Naturally, then, this will mean that de­sign de­ci­sions are car­ried out that may not nec­es­sar­ily ap­peal to you as an in­di­vid­ual but are likely to res­onate with your tar­get au­di­ence.

The chal­lenge for you and the de­signer is to find that happy medium where the de­sign speaks to the right de­mo­graph­ics but pleases you as a Product Owner as well. This phi­los­o­phy does­n’t just end at de­sign, but ex­tends to the func­tion­al­ity of the app as well. The per­sonas ac­tiv­ity is rec­om­mended in such cir­cum­stances. Every time a de­sign or tech­ni­cal de­ci­sion is made, you can re­fer back to the per­sonas to de­ter­mine whether the change is rel­e­vant to your tar­get users.

Our Guide to Creating a Successful Software Product will aid you in these de­ci­sion-mak­ing stages, which you can down­load for free be­low.

Another use­ful ac­tiv­ity for de­ter­min­ing the worth of a de­sign or func­tion­al­ity fea­ture is pri­ori­ti­sa­tion. Recognising that each piece of your ap­pli­ca­tion has a time (and there­fore ma­te­r­ial) cost helps to make crit­i­cal de­ci­sions about what ends up in your soft­ware. Alongside your trusted per­sonas doc­u­ment, you will be bet­ter po­si­tioned to de­ter­mine what fea­tures are ac­tu­ally go­ing to ben­e­fit your val­ued users.

5. Things can change

Don’t panic if the de­sign of your ap­pli­ca­tion does­n’t quite live up to your ex­pec­ta­tions right away. Design, like de­vel­op­ment, is an it­er­a­tive process and it’s quite nor­mal for the UI and UX to go through sev­eral ver­sions. Even dur­ing de­vel­op­ment it­self, as­pects of the de­sign may change or up­date. This is noth­ing to be alarmed about but is in­stead a nat­ural part of the de­sign process. In fact, your brand and ap­pli­ca­tion de­sign should be con­tin­u­ously evolv­ing.

Here are some fi­nal tips to keep in mind once you start scop­ing and de­vel­op­ing:

  • A de­sign sys­tem or brand can help steer your prod­uct on the right track. If you don’t have one, we can work with you to de­velop it.
  • Read up on UI de­sign and how it dif­fers from tra­di­tional print or even dig­i­tal de­sign
  • Don’t be afraid to ask ques­tions.
  • Understand that every it­er­a­tion of your ap­pli­ca­tion or brand is an op­por­tu­nity to col­lect feed­back.
  • And if all else fails, feel free to seek a sec­ond opin­ion. Gather feed­back from an in­house or 3rd-party de­signer to get their own in­sights.

If you’re pre­pared to trans­form your busi­ness with the help of soft­ware, con­tact us here.

Discover Software


Rhiannon Stevens

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

What is Agile Software Development: How to Start with a Problem

16 October 2020

The Advantages of Agile Project Management

09 September 2020

What’s the Best Agile Project Management Method For You: Scrum vs Kanban

11 September 2020

Your vi­sion,

our ex­per­tise