Welcome to the Exact Product Blog

On this blog we will cover stories from all around the Exact ecosystem.

Your feedback on the new request screen

Written by Edgar Wieringa on . Posted in Exact Synergy

I would like to thank each and everyone of you for your feedback to this post on a new screen design.

For the upcoming new release of Exact Synergy Enterprise we will amongst others deliver a redesigned screen for creating a new request. Since this is one of the most often used parts of our application we wanted to improve the user experience of it and needed to be sure on how to do this best. Not just the looks-and-feel but we want to support every user better in reaching her goals: starting a new workflow in a simple and easy way.

I hope that from my initial posting it was clear that we did think a lot about existing customers. Especially here we got a lot of requests to make this simple.

We have done user observations and user interviews at various sites where we literally looked over the shoulder of users. This was part of a project to get a better understanding of our users and their daily usage of our products. The current user experience. So it hurts me and my team when there is doubt on this (even in capitals :-)), you can however disagree whether we did this right. That conclusion I clearly make and we take the lessons learned humbly.

What did we learn?

  • For companies who show or have a limited set of requests the top x section might be redundant or too long
  • It was not a good decision to not make a distinction between the daily create request page and the maintenance page. Here we violated our own goal-directed designed approach. The users of these different pages have different goals when using them
  • Although also many people see an improvement we might have better not just replaced the old page but introduced the new one next to it
  • Since we value all your input, we will work on a way to re-introduce the IDs. One way or the other. Where our focus will be to still have an over viewable list. Where I have spoken about it hurts, it also hurts me when you guys are now putting the IDs in the description. Our aim was not to make your lifes more complicated. So point taken and we will work on a solution.

Last but not least we feel also strengthened by the many reactions, on the vision behind this to make the usage of Exact Synergy Enterprise more simple. That is one of the reasons why we on purpose didn’t choose for a setting, which was more a choice of design than a development decision. Here Andre Speek was spot on for our rational.

Thanks again for being a customer, business partner or colleague! We truly appreciate your replies and the engagement to our product and company this shows. I will update you later on how (and when) we take the lessons learned forward.

Photo credit: LiveFromAmsterdam

Tags: ,

Edgar Wieringa

I enjoy building software that supports your business' goals and people love to use. Hobbies: cooking, food, travelling, reading and running. Follow my work on http://twitter.com/edjewie

Comments (9)

  • Steffan Hoeke

    |

    Edgar,

    Even though (from our perspective) part of the redesign of the ‘new request’ screen is an improvement, we would like to see the list of requests presented in two columns (as with the asp version) instead of one.

    The main reason for this is that in the asp version we have *all* available requests on one screen without scrolling, where -with the new screen- we now lose that overview and have to scroll to see the entire list.

    Reply

  • Ronaldo

    |

    Edgar,
    I fully agree with Steffan. If you have many request types, than you have to scroll. This isn’t ergonomic. I showed this “new” screen a few customers and they have mixed feelings, especially with top section – nobody remembers ID of each request and lack of two columns as in previous versions.
    Please take into consideration developing possibility of translating tittles of request categories , tittles of request types and particular fields of request for different languages. This is real problem for international customers. Currently, you can choose interface’s language but crucial functionality doesn’t support it.

    Reply

  • Ronald Voets

    |

    @Ronaldo Thanks for your response. Translation of requests is something we’ve heard from more customers using Synergy across multiple countries (or have users from various nationalities). It’s on our product planning to offer translation possiblities for the (free) fields, labels and sections that users see on a request,

    Reply

  • Martin

    |

    Today I had a nice talk with one of the persons how strongly believes that the numbers should be back. After a short discussion the conclusion is that we don’t need the numbers, but…
    – If you don’t provide them, be consistent; when i select to create a task and use the search in the new request screen, the system gives me back the ID instead of the description. When i select to report on a request, in the filter field in shows me the ID instead of description.
    – In the new request screen, give the option to sort the request groups. this functionality is removed.

    when these two are back, the numbers indeed are no longer needed

    Reply

  • Edgar Wieringa

    |

    @Martin,

    You are right about showing the ID. This is one of the losses you sometimes have to take as a product manager. Due to technical constraints we currently can’t show the description over the ID in the input field.

    Or you can also read it as I could not give the technical team the time to build it as we ideally wanted it to be. So we had to make the choice to deliver it as is.

    Thanks for your input and investing the time to explore this.

    Reply

  • Ronaldo

    |

    Ronald,
    great news. It might be a really competitive adventage and a strong tool to get enterprise customers worlwide.

    If I can continiue my customers wishes, please thnik also about supporting Firefox or Mozilla. Unfortunetely many people want to be “independent” and use Apple products, etc. We loose many prospects by this constreain. I finished my wishes :)

    Regards.

    Reply

  • Rob

    |

    Hi Edgar,
    As a user, the ID of a request is not often used.
    However, in copying requests (for sales or consultancy) it is handy to have the possibility to show them, or get an overview of them.

    Further, the use of one column with all requests is absolutely not user friendly. With an extensive range of request types, it is not working for me.
    I would prefer the possibility to make multiple (2 or 3) columns and arrange the categories in my own way (pretty much like a search screen or account card.

    Reply

  • Deepthy

    |

    Hi Edgar,

    From the release 242, when we are creating requests from the new search text box, its listing the hidden requests as well. Users are able to create a new request even if it is actually hidden.

    Reply

  • Edgar Wieringa

    |

    Hi Deepthy,

    Thanks for your reply. I noticed your issue as well, you however touch an interesting topic here. A hidden request has always been a bit typical to me, so I would like to understand for what kind of situations you use it. Hidden request are not shown – they do not occur in the long list of request type at the bottom of the page for instance – but for thosew who know them, they can create them. In the past these happy few, could just create there request by entering the ID.

    Only allowing a group of people to create a certain request can be done by other means (attach a role or use security level). Based on your reply I would like to learn when you guys use it.

    Fixing the situation is relatively easy, however hiding it from the auto-complete would however result in the auto-complete list giving you a ‘No data found’ whilst you can create the request, this I would not find great.

    So you are right that this occurs, jsut help me know in solving this.

    Thanks again for your post and in this way engaging with us,

    Edgar

    BTW. We also had an issue that inactive requests where shown, this has been fixed along the way in 242.

    Reply

Leave a comment