User experience practitioners often end up needing to disentangle the web of asks and turn those into solid requirements that are actionable. Requests typically start quite broad when working with a team that doesn’t have experience with UX designers. It then falls on us as UX experts to help tease apart the real goals, and solidify them as agreed upon requirements and use cases. In the following example, I’ll walk through this process as I recently did it for JBoss Developer Studio’s Central Page, a welcome page on our version of the Eclipse IDE for JBoss Developers.
The request
As shown in the JIRA JBIDE-18813, the original requirements were stated as follows.
[JBoss Developer Studio] Central Page requires new capabilities :
- needs more customization (display content depending on user preferences)
- needs to scale with JBDS-IS, Fuse content
- access to more examples, with filtering capabilities
Gathering more information
We know that we’re working with JBoss developers for this functionality, but there could be some different personas who require different experiences from this functionality based on their level of experience with JBoss products. I started by identifying the main goals that users might be needing when they open their IDE and see JBoss Central. This information was gathered through discussions with JBoss developers, past experience with the products, and a SME (subject matter expert) who could talk towards JBoss Developer use cases.
We then had a meet-up with the team to discuss these and the original requirements. From this discussion, we agreed on the user flows and generally agreed that customization was a requirement only because you could not see a variety of content in the current Central Page design – so if the new design addressed this in another way customization might not be necessary.
Wireframing for further discussion
Once the team had some general discussion about the user needs and requirements, I felt that putting some wireframe concepts together to further focus the discussion would be the correct next step. The initial round of wireframes had a variety of directional choices for the team to select from, allowing further discussion about the goals, users, and requirements at a more detailed level.
From these design concepts, it came to light that the “non-written” requirements that the team was interested in was a modern, simple welcome page. They wanted easy entry for beginner and experienced users without as much visual clutter as they had in the past, and design option C fit the bill for them. With discussion of a few small modifications, we were then able to move forward with Design C as the path for high fidelity designs and HTML/CSS creation.