.png)
Industry Dive created a new product to package a curated list of articles for our readers. To solidify product requirements before creating a more permanent solution, we coded the first few by hand. After a successful launch of the hand-coded content packages, we decided to streamline their creation and empower our editorial team to build them independently of the tech team.
My job was to take the product and create a proposal for the internal creation process. Here’s how I narrowed down requirements and created a solution.
Define Requirements
I always start my projects by asking what’s the problem we are trying to solve? The answer was pretty straightforward this time: Industry Dive has a new product that is currently created by hand. We need a sustainable process to allow the editorial team to assemble the product.
My first step to define the user process was to figure out the requirements of the product. Because it was a new product, many departments had differing views on the priorities and needs. To assess what mattered to each of the stakeholders, I held meetings to answer two questions about each exisiting feature of our current product:
1. Is this feature a “non-negotiable” or a “nice to have”?
The importance of a feature decides its hierarchy in a complicated UI and defines the time spent on perfecting its UX.
2. Is this feature required for multiple stakeholders?
Determining which features will be used by which stakeholder(s) ensures we can optimize the user experience when we get to user flow and wireframe designing. If multiple departments plan to use a specific feature, we need to consider all of those teams’ current processes.
I compiled the results and broke them down by company needs and department needs. The list not only defined requirements for myself but also provided a reference for each department. It even laid the foundation for the decisions I would be making later on in the UX research process.
Define Relationships
Next, I split the requirements into three groups: initial content creation, editing content and content assembly. I then visualized how these requirements relate to each other by asking myself specific questions. These questions guided the user flow iterations and helped refine the relationships.
1. What order should the user be interacting with these states?
I arranged the features in the order the user would need to interact with them by examining current UX patterns in our content management system.
2. Which features are dependent on specific actions?
Once we defined all the explicit requirements, I started linking and grouping them according to user actions. I noted where features blocked each other and where they could be completed simultaneously.
3. Which implied features have I not listed out?
I then audited the flows to catch the required features that might not be listed in the requirements. This included features like the ability to save steps in the process or delete content.
4. What features and relationships can I do without?
While I added features, I also removed the ones that weren’t necessary. I also removed excessive feature linking, such as four different ways to navigate to an edit screen. Rather than giving the user more clarity, these extra links caused confusion.
Define the wireframes
After the stakeholders approved the user flow diagrams, it was time to move toward wireframes.
While the user flows helped determine what should be on each screen, I needed to ask new questions to determine the wireframe layouts.
1. What existing patterns can I borrow?
The first step was to bring in patterns that are consistent across our content management system. This project had similar features to current solutions so I could mimic existing layouts.
2. What is or isn’t working?
Once I laid out the initial requirements with existing patterns, I wanted to ensure each one was a pattern that optimized the user experience. This was my chance to identify room for growth.
3. Where is there room for innovation?
To improve existing patterns that were subpar, I took a step back and brainstormed different ways to solve the problem. Rather than using the easiest idea, these features benefited from a variety of different ideas that pushed the envelope.
4. Can I make this reusable for other problems?
While brainstorming new ideas, I also kept the entire content management system in mind. Creativity is necessary but if the team spends a lot of time implementing a feature, I want to make it reusable for future projects.
Next steps
These defining questions helped me create a functional wireframe to present to stakeholders. Based on their feedback we refined the process into a user friendly proposal. The next steps are breaking down the screens into tasks for the development team to get started on.
