Client Interview App
The project started with an assessment of how Solution Engineers were running interviews. They were using a spreadsheet, endlessly scrolling to find questions, copy pasting answers and questions as they went along: a time consuming and uncomfortable experience.
Solution Engineers work with clients to create bespoke apps and dashboards. One of their main jobs, is to gather client requirements efficiently and effectively, so that the solution built is as good as possible.
The Solutions Engineer at the company were using a question bank, stored in a spreadsheet. To create a new interview and run it, they had to copy the spraedsheet and work on it as they were interviewing the customer. The questions were many, and nested under many level of possible branches, making the user flow quite complex to map.
The first step was to interview Solutions Engineer to understand what they liked and disliked about the current solution and their goal. I asked about the context in which they run interviews, especially about device types, access to the internet, if they had assistance of a colleague. Top user pain points were:
Too many questions to scroll through The question bank is vast, and even though they were categorised, they were hard to scroll through in a spreadsheet.
Scoring was not simple Each answer had to be typed and then scored. Scores had to be entered in a cell, and it was hard to respect scoring guidances that were scattered in the spreadsheet.
Lack of a summary After the interview, the team reviews the answers and scores to brainstorm solutions. The spreadsheet does not allow to easily get a summary of the entire interview, making the brainstorm cumbersome.
The first step was to create a clear user flow that would be comprehensive of happy path and unhappy path. This was reviewd often by the major stakeholders to ensure my understanding of the process was correct.
After designing the flow, I concentrated on the key interactions in a low fidelity prototype.
From low fidelity, to high fidelity prototype, I tested the experience with volunteers solutions engineers and gathered some feedback. With this feedback I could improve.
Question dependency If an answer to question A was ‘Yes’, a subset of questions should pop up, for an answer of ‘No’, another set of questions should pop up. This interdepency made the job more complex, but also more interesting.
Asynchronous scoring Some Solutions Engineers feel confident scoring answers as they go, while others feel more comfortable scoring after the interview is over. It was important to give a space to review answers and score at any time.
After those iterations, I produces a mid fidelity prototype in Axure that was then used as the basis of high fidelity UI designs.
These designs are excellent. You interpreted our requirements exactly as we'd described them e.g. the drag and drop functionality for individual questions, and added in some additional functionality which is incredibly helpful e.g. the keyword search bar during the interview section. This design would certainly lead to an intuitive, flexible tool which would react quickly to a live interview situation.
Head of Solutions UK, MiQ