Computacenter

Competitive Analysis

Right after getting clarity on the requirements and user stories it was time to do analyse products that are already out there in the market.

Why this was important?
Product competitiveness: Computacenter were designing this product with a view to sell it as a service to other companies. The prospective clients may have been using a different product or none at all. Thus it was important to consider some of the main competing products out there so that -

1. we get to assess the capabilities and compare them with the requirements this far
2. we ensure that we keep the user journeys industry standard as much as possible unless of course we find a better way for the user to achieve their goals
3. initial wireframes - this will give us a good understanding on how similar issues are being tackled already which prevents us from re-inventing the wheel each time

Some of the main competitors in this space were:

1. Service Now
2. Fresh Desk

Below are examples of how the competitor analysis were carried out using ‘Service Now’ as the competitor

A similar in-house tool used by Computacenter for listing Incidents

The interview format and protocol

Hi (participant),
Thank you for making time to talk to me today. As you might know, we're meeting people like you to understand your the needs and preferences that you believe employees have around the importance of My Request in the existing company request portal.
In our session today, I’ll be asking you general questions around this topic. You don’t have to worry about giving the right answer, because I’m merely interested in understanding your opinions and perspectives. We should take about 30 to 45 min to complete this session.
Please be assured that your comments will remain anonymous, and will only be shared as aggregated responses.

Interview questions

1. Do you have any questions for me before we start?
2. Participant’s understanding of their role
3. To start with, please tell me a bit about your current role and responsibilities.
4. Why do you usually navigate to this My Request page? Check requests - 80%
5. How would you describe this web page in one or more words? All over the place; does the job; need training
6. How does this webpage compare with other similar functionality driven web pages like Amazon's My Orders? User interface of Amazon is much better | More search options in Amazon
7. If you were to review this page what score would you give it out of 10? 6
8. What do you find most frustrating about this page? Layout -70% | Navigation and content - 30%
9. Overall, how easy did you find this page for checking your request details and status? Very easy
10. If you could change one thing about webpage what would it be and why? Layout -80% | Notifications - 20%
11. Are there any features in this page that you find outstanding? None
12. What do you like best about this page? Simple
13. What do you like least about this page? Layout/Structure
14. Anything else you care to share or get off your chest? Usually slow
15. Would you recommend this page to a friend or colleague? If “Yes” or “No”, Why? No - "structure of page; speed"

Affinity Diagram

In order to capture the needs and ideas to solve the main problem at hand - 'How would individuals check the status of their submitted requests?

Primary requirements:

1. Need a digital interface for users to check the status of their requests

Secondary requirements:

1. Interface needs to be in alignment with an already existing system
2. Interface should be capable to read out the different stages of a request
3. All of the interactions and elements in the interface should be intuitive to the user

Because it is a known fact that the needs identified by the product owners can be very different from that of the users, this exercise was carried out with some users as well.
Here, I will list a combined view of both diagrams (one with users and one with product owners):
First set of thoughts with the categorisation which followed after all of the thoughts were listed with sticky notes

1. Who is the request for
- Goal
2. Checking the status of the request
- Goal
3. Date of delivery
- Content
4. Where does the user start the journey from?
- Navigation
5. What level of details will be available for the user to view?
- Content
6. Stages of request
- Process
7. Approved
- Status
8. Approval declined
- Status
9. Left a note
- Goal
10. Requests from Draft?
- Function
11. Copy request functionality
- Function
12. Copy request journeyl
- Goal
13. Copy request
- Goal
14. Copy request for someone else
- Goal
15. Fulfilment details
- Content
16. Request closure verification (RCV)
- Process
17. Request closure verification (RCV) journey
- Goal
18. Where would RCV appear?
- Navigation
19. More information needed by approval
- Content/Process
20. Who can view the information
- Process
21. Notifications
- Navigation
22. When to serve notifications?
- Process
23. Deep linking page from email?
- Navigation
24. Which request should be opened by default?
- Process/Navigation
25. Information from ITSM -
- Content
26. Arranging information from ITSM
- Content
27. Request questions and answers
- Content/Navigation
28. When the request was submitted?
- Content
29. Where would the request submitted date appear?
- Navigation
30. Check the request submitted date
- Goal
31. In progress
- Status
32. When was the request approved?
- Content
33. How would the user view the dates that approvers approved?
- Navigation
34. What would that look like?
- Content
35. Would the approved date and date received by the next approver always be the same
- Process
36. When was the request declined?
- Content
37. Why was the request declined?
- Content
38. Who declined the request?
- Content
39. How many approvers are involved in the request?
- Content
40. How many have approved so far?
- Content
41. How many are yet to approve?
- Content
42. Find a particular request
- Goal
43. Request ID
- Content
44. Items requested in detail
- Content
45. Find the names of items requested and the cost
- Goal
46. Cost of item
- Content

The above items were then re-arranged in their respective headers.

Card Sorting

In order to capture the needs and ideas to solve the main problem at hand - 'How would individuals check the status of their submitted requests?

The activity: 9 end users were picked and split into a group of 3. They were then introduced to cards containing phrases obtained from the Affinity Diagram (step 4) (some of them have been illustrated below).

Based on the scenarios outlined below, each group was asked to pick up the most relevant cards pertaining to the scenario at hand - in conjunction with the goals identified from the Affinity Diagram (step 4 - see items under 'goals').

Some card examples:

List of scenarios

1. You requested some Computer Peripherals. What would you expect to see when you want to check the status of this request?

Example groupings:
2. You requested some Computer Peripherals. You've been notified that this request has been declined What would you expect to see when you want to check the status of this request?

Example groupings:
3. You requested for a software called MS Visio. This item needs to be approved by 4 people. When you checked the status of the request - it said 'approval pending' What else would you like to check?

Example groupings:
4. Which of these cards would qualify towards defining the status of any request?

Example groupings:
5. Could you please re-group the cards you selected for scenario 4 into smaller groups in a way you find most logical?

Example groupings:

Information Architecture

With sufficient valuable information at hand extracted from the above steps, it was now time to sort out the Navigation and Content Strategy.

Sitemap of the page

Flow - Request Portal

Generation of wireframes

After a good understanding of the page's desired navigation and placement of content to attain user goals, it was time to prepare the wireframes which would be put in use and tested against, in the first Usability test.

First set of mid fidelity wireframes after some stakeholder and end user interaction

Usability Test - 1

Once the clickable wireframes were ready, the next step was to test the wireframes capabilities and usability of attaining goals that were identified in the Affinity Mapping process.

About the test
The 8 participants who participated in the User Interview were the participants of this testing exercise. They were given some scenario led tasks to perform so as to attain the goals we identified. For qualitative analysis, the participants were asked questions as they carried on with their appropriate journeys.
It was clarified to the candidates that it is the system we were testing and not themselves.

GOALS

1. Checking the status of the request
2. Read the note left by approver
3. Copy request
4. Copy request for someone else
5. Request closure verification (RCV) journey
6. Check the request submitted date
7. Find a particular request
8. Find the names of items requested and the cost

Task list

Top positive comments
"Much better layout than the old system"
"Easy to understand the progress of the request"
"I like the fact that delivery date can be estimated"

Top Negative comments/ behavioural observations
"Confused about the stages of the request"
"How do I check the questions and answers?"
"What are these tabs for?"

Conclusion
The test was overall a success in terms of getting the primary problem solved - 'checking the status of the request;
However many of the secondary goals such as 'viewing questions and answers' were just not intuitive as user journeys for the candidates.
Largely, candidtates were able to relate to some of the actions with the old system - such as 'view complete log' relates to Audit.

Recommendations
A few changes in the wireframes may be needed to make the navigation between tabs easy.
Some information about Fulfilment may need to be accessible to the user.
Journey for viewing 'Questions and Answers' need to be re-worked.

Wireframe enhancements

Second set of mid fidelity wireframes after the Usability test and some stakeholder meetings:

When the tab 'Waiting for approval' is clicked.

High Fidelity Prototype