Feedback on new request screen

Posted on 21. Jun, 2009 by in Exact Synergy

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.

new-request-full-screen-small

Click image for full-size

So we did quite some research with a set of customers on how they use the current screen, how many request types they have, which ones they actively used et cetera. Now that the new screen is in controlled release we get mixed feedback on one specific part, via this post I would like to open up for more feedback to make sure we deliver the right experience to you.

Our user research learned us a couple of things which resulted in these design principles for the new screen:

  • an average company will have over 50 different request types
  • most users use about five to ten of them frequently
  • the request type categories are not very well known within the user group
  • searching for a specific less frequently used request is quite cumbersome and only a limited number of users is using the search option of Internet Explorer [CTRL+F] for this
  • the request ID box is only used by a limited number of user to create a new request
  • the majority of the users is unaware of how to use it or what to enter in it

Based on the findings we have redesigned the looks and working of the screen with the following three key parts.

  • A list of the requests most used by you as a person
  • An easy way to create a request by ID and request name
  • A list with all available request types

snapshots-small

Click image for full-size

The mixed feedback is especially on this last part. Since during our research we learned that a limited number of users where aware of the request type IDs (e.g. a Vacation request is number 103) we did not include them in the list. The ordering used to be on number but for people it is easier to scan alphabetically since the name of a request gives a better understanding than the number. For the unaware user it was hard to scan the list we learned. So our aim was to increase the readability and hence an easier recognition by just using the request names. The users which now the IDs are still served by the request creator, in this field you can either enter the code or the request name.

Via this post I hope to get more feedback on especially this part. Should the request IDs be re-introduced in the list and even more important what is for you the reason to use it? Maybe as a last remark, removing the request ID was not a goal by itself. During our user research of the last year we often got the feedback that the screens of Exact Synergy are quite loud, they offer a lot of options. Redesigning the complete request page has been done with keeping this in mind, make the screens easier to understand by offering less options and the options offered are a perfect fit for your goals. Please reply with your thoughts!

Tags: ,

35 Responses to “Feedback on new request screen”

  1. Brenda

    22. Jun, 2009

    Even as an advance user, I wouldn’t remember the ID too much. When I create a request, i would look for the description. Taking the ID away would be good to keep the interface clean.

    Reply to this comment
  2. Andries Warreman

    22. Jun, 2009

    The only reason that I use ID’s is when someone asks me to enter a specific, for me until that moment unknown, request type. In order to find and use that request quickly the ID is entered.

    Reply to this comment
  3. Patrick Meeder

    22. Jun, 2009

    For people who know more about software than an average user in a company (i.e., technical people), request ID is shorter to remember than the complete name of the request type for the requests that are used mostly. At customer Cordaid, we (consultants and customer IT department) often talk about creating request type 600 and including types 600/620/630 in reports. For technical people, ID can be important to remember and to quickly create a request.
    I agree with all solutions in this document, except for leaving out ID. I agree that alphabetical order is more logical to search for (at Exact, I indeed use CTRL+F to find something which is not very efficient), so ID should then be included to the right of the description (e.g. between brackets).

    Reply to this comment
  4. Jo-An

    22. Jun, 2009

    Even as a very experienced Synergy user, I never use the request ID to create a new request. Simply because I do not memorize the ID. There is no use memorizing it, because at Exact we do not have a logical order or use of the ID, e.g. all absence request IDs start with 2 or something similar. For item codes this is a different story. We do use item codes in a structured way, e.g. all modules for Synergy start with YA.
    I would leave the request ID out of the standard new request screen and allow users to add it via a Customize if they really want to use it.
    I think the screen will greatly improve if the most used request are listed on top, like in the first screen in this article. For the other request types, I would recommend to have at least 1 sort / group option. Not only show them by category but also allow the user to sort the request types on alphabetical order (regardless of category). This saves a lot of time…

    Reply to this comment
  5. André van de Graaf

    22. Jun, 2009

    Keep It SImple. There for remove the ID. The ID needed from a technical perspective. To identify the request. A user has no influence on the value of the ID when creating a new request. So no logic in the ID vcan be build. Like Item codes you can use logic in your item code to identify different types of Items.
    With the ID in requests this is not possible. So from a user perspective the ID has no value. A user should be able to FIND the request he is looking for. A search on the name should work. A search on ID is only a work around in case the search on name does not work. There for the root ccause need to be fixed. Search on name whould work, then IS is not needed. This will keep the interface clean.

    Reply to this comment
  6. Sonja

    22. Jun, 2009

    I’m also an experienced user, but do not create requests by the ID. I agree that for a design, it is usefull to have the ID (since the description of the request type can change). However, majority will not use it. Therefore I would agree with leaving it out.
    My first thought after viewing the screen was: for ‘new’ users, this screen is very confusing. I can enter something (but probably only a number), but cannot make a link to what I can enter (since no ID is shown behind or in front of the request type).

    Reply to this comment
  7. MARC

    22. Jun, 2009

    In the new screen only the request id are shown you frequently use. If you want to use sometimes a special request id you have to know the name. So why not a button extra were all id’s and requestnames are displayed so you can look for it in a new screen. You wont use it often, but you have all requests and ID’s available.

    Reply to this comment
  8. Andre Speek

    23. Jun, 2009

    Many of my customers use the ID’s often. One reason for that is that I include them in instructions and manuals. The description of the request type might change over time, but the ID will always be the same.

    Also, especially in larger organizations where you have many request types, some of them might have names that are quite similar. In that case, the ID seems easier to remember and is more specific.

    Personally I also feel that those long lists are also the result of a “bad” implementation. If you use the HR Roles for creation and other options you have to hide request types from that screen, you don’t even have the problem as described in the first place, except for an administrator maybe. Further optimization can and should be done by creating startpages and give clear instructions on the use of favorites.

    Still, I like the “recent section” on top and the use of the typing box where you can also enter the description now. Surely is an improvement.

    Cheers,

    Andre

    Reply to this comment
  9. Andre Speek

    23. Jun, 2009

    @Jo-An:

    Quote: “There is no use memorizing it, because at Exact we do not have a logical order or use of the ID,”

    Seems more a problem of not taking enough time to design a good structure. The ID isn’t auto generated so it has gotten a “functional” value over the years.

    And also… Exact asked her partners to create 261′s now instead of the 103′s and 149′s when the request types changed. The numbering, however irregular it might be, seems to be memorized by some people though.

    Reply to this comment
  10. Edgar Wieringa

    23. Jun, 2009

    @Andre Speek

    Thanks for you extensive reply, it really helps to get the insight. What I am also curious about on how you refer to document types in your process instructions. This was also upfront one of our reference points. Document types also have an ID but that is basically only disclosed in the maintenance applicaiton. Do you also here use these in your documentation?

    Reply to this comment
  11. Marcel Steenhuis

    24. Jun, 2009

    In daily use I do not use the ID field often. In implementation of Synergy at customers, I do find this field handy in use and would therefore opt for reintroduction. When testing new request types, I have found the ID field the quickest option to create new requests. Possibly the ID field can be flexible in presentation i.e. a user can indicate whether they want this presented or not.

    Reply to this comment
    • Edgar Wieringa

      24. Jun, 2009

      @Marcel,

      Thanks for sharing your insight. I hope it was clear to you from my article that creating a request by ID is still possible, it is ‘only’ removed from the list of request types

      Reply to this comment
  12. Andre Speek

    24. Jun, 2009

    @Edgar,

    As you mentioned, the ID’s for Document Types are generated and hardly visible. Therefore one can only stick to the description for documentation.
    Also, many companies (and consultants) still rely more on the Categories then on Document Types. Probably because Categories where there before Document Types.
    And in general, most users create more requests per day, as they do documents. Documents that also are often generated from MS Office. For Outlook, the Categories are mandatory (why not the Document Type?) so a lot of times the user doesn’t even think/realize where the Document is stored.

    Reply to this comment
  13. Heather Barr

    24. Jun, 2009

    Most of my customers do not use the ID. Internally, I remember very few of the IDs and have to scroll through the extensive list. I really like the frequently created section.

    Is it possible to have the id search criteria and display id as a setting that can be turned on and off based on the users need. Default the setting off, and for those users who find it helpful, they can add it? I know this is done for some of the other search screens, but not the create…so I am not sure if it is a valid option.

    Reply to this comment
  14. Andre Speek

    25. Jun, 2009

    A setting could be an option, but then again… we should be aware that there are a lot of settings already throughout Exact Synergy… Besides, right now there are no other settings for Requests/Workflow so it would also mean a new screen would have to be introduced for this.
    If I would have to choose, I’d say rather leave the ID’s out then to introduce a new setting. Since the possibility is there to create a new request by entering the ID, that should do. Also, the ID could still be made visible in a tooltip when hovering over the description.
    Still, every time I’m surprised to see those long lists of request types. There are good ways to clear up the screen by hiding request types or using the create roles to surpress them for those users that don’t need them. Hide them from this screen and make them available through special startpages can also be considered. I have customers with over 200 request types and still we can manage to keep this screen clean (20 request types max, neatly grouped) for the average user.

    Reply to this comment
  15. Scott Leete

    25. Jun, 2009

    I like the clean, simple look of page without the IDs. Personally, I think it is always difficult when you remove functionality that previously existed–even in the spirit of Ux. I like the suggestion of having a link to a settings page (customize icon) that would allow the user to show the ID number, but not display it by default.

    I have experienced frustration in using this screen because I have to scroll down the screen to get to requests that previously would have been visible previously. I know the single column was supposed to improve the user experience, but it did not for me. I will say, though, that I did not realize the search box at the top accept text and not just the ID number now. (Make sure that you mention that enhancement in release notes/documentation). What are the search criteria? Contains or starts with?

    Reply to this comment
  16. Quirijn Vermeulen

    25. Jun, 2009

    I agree that without the ID numbers in front of the requests, the overall view is a lot cleaner. I like the fact that it looks less cluttered this way and it’s easier to scan the list for the request type you’re looking for now that you don’t have to scan past the numbers first.
    I would think that instead of a single column, two columns would be better to prevent having to scroll. As you mentioned, most companies have over 50 requests, therefore scrolling would be needed for the users of most companies.
    Also, I would change the screen slightly so that the ‘(multiple)’ options (for multiple requests) are in a separate column, thus aligning neatly below one another. That would further clean up the interface.

    Reply to this comment
  17. Jasper Harlaar

    25. Jun, 2009

    Great idea with respect to the Request ID. I never reference it (no pun).

    I am not sure how the most frequently used Requests are presented but maybe and algorithm (big word for me) could be used to learn a users preference…

    Reply to this comment
  18. Fred

    26. Jun, 2009

    In order to have the possibility to show a process in logic order the ID is perfect. It is possible to influence the ID when implementing Synergy Enterprise :-p. With respect for colleagues who never use the ID they have to use the mouse. Takes more time. Most likely they also will not use the shortcuts (alt-s etc). If no ID is available and alphabetical order is used we have to create names like 00 Hour Planning, 10 Consultancy, 20 … Leaving out the ID is not a good idea.

    Reply to this comment
  19. Aritz

    02. Jul, 2009

    Hi everybody.

    I think is a next step in the evolution of Synergy.
    I like the new interface, specially, the last request used recently area.

    But, i don’t like too much, that if you have a lot types of request only you can see in one column, so, maybe it can be a bit unuseful.
    I think it would be better if they could view in two columns at least.

    Reply to this comment
  20. Robert Klein

    04. Jul, 2009

    i concur with Heather’s idea “Is it possible to have the id search criteria and display id as a setting that can be turned on and off based on the users need. Default the setting off, and for those users who find it helpful, they can add it?” I agree, I have used it once and I have never seen anyone else use it.

    I wish there was a way to hide request types you never use. The alphabetical listing by category makes sense. It would also be nice to have an option to sort by most important, or most used by a category.

    Recently created is nice! How about a user option to create there own menu and to be able to put them in your order, much like create a favorites listing and adding a number e.g. 1. to create an order listing.

    Reply to this comment
  21. Erik

    15. Jul, 2009

    I am not happy with the changes in 241 regarding leaving out the ID. I can understand why these changes have been made, but in fact a lot of users are still using the ID, since it is much shorter to remember than the description.

    Reply to this comment
  22. Scott Leete

    15. Jul, 2009

    The absence of the request ID makes it very difficult to determine a range of requests to export via “Request Type” XML. It would be nice if the request id was at least display in the workflow definition maintenance screen, WflRequestTypes.aspx

    Reply to this comment
  23. Quirijn Vermeulen

    24. Aug, 2009

    Since the verdict seems to be split between people who want to see the ID and people who do not want to see the ID, why not make it an option to show the ID under the settings. That way people get the decision if they want to see the ID’s (and perhaps sort on them) or whether they do not want to see the ID’s and sort alphabetically within the request groups.

    It may be more work to implement that way, but it leads to a screen with more functionality that will be pleasing to work with for most people and you give the user control.

    Reply to this comment
  24. Menno Verbon

    14. Sep, 2009

    It’s a horror. We now have to add the ID’s in the description field in order for people to work with requests. We’ve been using the id’s in our company for over 5 (FIVE) years and everybody knows them. I a lot of screen you have to enter the id’s so why has it been hidden.
    It’s a shame that Exact do NOT think about existing customers and installations. A good developer would have made this an optional choise. In that case everybody would be happy. Now we have NO choice and have been FORCED this functionality.

    Reply to this comment
  25. Edgar Wieringa

    06. Nov, 2009

    For those of you who haven’t noticed yet, I have replied to all your valuable views in this new post.

    Reply to this comment
  26. Danny Bonthuis

    23. Nov, 2009

    The only thing that I really like about the request screen is the top ten, that is a big improvement…but I miss the ID’s. and the list of requests is now really long so a lot of scrolling and searching….

    After 6 hours of working actively in 242 I can still stand by my innitial thoughts and the feedback given by customers during the Controlled Release faze of release 241 where this screen was introduced.

    Reply to this comment
  27. Christian Ibetsberger

    17. Mar, 2010

    We also used the IDs to create a sort order other than alphabetical. Requests for general purposes are always on top, those for specific purposes are on bottom of each category. Sometimes the sort order also follows phases, for example in the HR application prozess.

    We do not miss the IDs other than for that purpose, since it is always possible to create a request by entering the ID if it is known or noted on a document.

    The request screen would look ‘nicer’ if the colours would be shown again (I m a visual user) – even if its of no use otherwise. by different colours it would be easier to distinguish the categories when scrolling.

    In the recent used pane there is no reference to the category and the order of the entries changes according to the used requests. Again a color ‘code’ might help spotting right request or be a ‘reference’ the color of a category.

    For customers with less than 50 requests, two columns would be way easier (no scrolling). For customers with more than 50 requests I wonder how they manage with the short request descriptions. The description field should be longer.

    If I had to programm this I guess would simply have made a setting for the number of recently used request you wanna see, for example 20. And then show those 20 in two columns with categories, and a button to show all instead in the same layout. That way, users can choose to see recent 10, 20, 50 (what fits on one screen or even all). The more recently used requests you choose, the less will the position/order of the requests change.

    Reply to this comment
  28. Christian Ibetsberger

    17. Mar, 2010

    Additional note to my idea above: It a certain (>10) number of requests is shown it would be more efficient to be able to ‘expand’ a specific request group to show all requests. It is not neccessary to to show all requests of all categories.
    So I would see all requests groups and all f.e. 30 recently used requests and I could expand the 1 group I m interested in to pick a request that was not recently used.

    Reply to this comment
  29. Shawn Gamble

    25. May, 2010

    I agree With Christian about being able to Expand and Collapse the workflow groups. Infact I have Enhancement request 34.517.085 created for this specific task.
    In my Environment I have some groups that have 200 plus Workflow it is a pain in the butt to scroll through pages of workflow to get to the one your want. some people just would like to collapse Large groups that they know they have no interest in using.

    Reply to this comment
  30. Maarten Tigchelaar

    22. Jun, 2010

    Additional note. The start of a procesflow should be integrated into this screen as well. Now users have to click on a button to see the available procesflow options. Most users don’t know the difference between a single request or a proces flow.

    Reply to this comment
  31. Petr

    14. Nov, 2011

    I find this screen (Request: New) very confusing, even for experienced user. In my opinion, it does have the right elements (features) – but they are implemented in user “unfriendly” way.

    Example 1: I am about to enter a new request, for which I do not remeber name, nor ID – therefore I start typing some name, which I think is right – a promissing shortlist displays but suddenly, a number shows up and jumps in the ‘Regest type’ field and I do not know whether it corresponds with the name …

    Example 2: I decide to scroll down trough the list of available processes to find THE ONE – I see categories and within each category I see requests sorted by alphabet – fine. However, I cannot sort it by alphabet regardless of the category – uff.

    Here is what is suggest:

    1/ List of recent / most used on top (req ID in the brackets)
    2/ Searching by name
    3/ Show more options control (something, which just shows hidden part of the screen, so nothing like a link to search screen, which is contacting server and waits for response
    In this section: multiple search criteria (name, category, security level, role, color, manager, mail merge, etc.)
    4/ Results set / section with option to sort by any column

    What do you think?

    Reply to this comment
  32. John Clark

    08. May, 2012

    I woud suggest the feature for the recent requests and the drop down capability also be added to the create a new document page. Right now it is horrible to create a document you have to find it in the list and then click on it instead of just typing it like in the request. Also would be nice to have the frequently used documents post at the top.

    Reply to this comment
  33. Sunil Girdhari

    11. May, 2012

    Hi John and Gary,

    Thank you for your valuable feedback.
    We will definitely take this into consideration as a feature to be added in the near future.

    Reply to this comment

Leave a Reply