Due to the urgency with which today’s companies and entrepreneurs must launch technology projects, software development teams generally prefer an agile process that involves rapid sprints, each with a specific list of requirements. But sometimes a project timeline is so short, it becomes impossible to foresee, and accommodate, all the possible user paths around a specific task. Frequently, this forces a team to reverse-gears on the process, in order to understand the gap and implement a fix. In the case of a non-linear system, (i.e. a system that doesn’t just have one specific user path, but several) the issue of updating the navigation flow around a specific task may be exacerbated.
To give some sense of the importance of foreseeing this issue, imagine you’re working on an aircraft model. You might be eager to open the box and put together the pieces without following the instructions, gluing the pieces together, one by one, until the aircraft looks like the one on the box. But in the end, you find you have 2 or 3 pieces left and don’t have a clue where they should go on the model—until you finally review the instructions. But now it’s too late to add them. The pieces are already glued and can’t be separated. You now display the model on a shelf, but you’ll always know it’s not complete.
The design process sometimes starts the same way, with just an idea of what needs to be designed. Designers can usually start working with just a bit of direction, maybe even start creating wireframes and UI design to obtain feedback. But can this process technically be called “agile”? Does it cover the requirements of the sprint? And if so, will it be easy to go back and fix any gaps we failed to cover (by not gathering all the necessary information) from the beginning? In my experience, delivering a UX/UI design that doesn’t conform to business rules or accommodate all possible usage-scenarios, adversely impacts the relationship between the development team and stakeholders.
First, we should all avoid the tendency to get started with design after receiving just a few instructions from customers or project managers (I’ve personally tried to mitigate the issue though various processes, meetings and tools). The most effective strategy I’ve found has been to literally keep stakeholders away from any early layout and UI concepts until it’s time to actually work on them. Differentiating between the problem, the solution, and the visual representation is the best way to approach agile design processes.
Identifying User Tasks
When design teams start designing, their primary motivation is to provide benefit and delight; users must feel immediately comfortable enough with the product that they won’t abandon it. This is the goal of any product. Next, the priority is to identify tasks the system will allow (e.g. creating an account, searching for a user, chatting with users, uploading a picture to a timeline, creating a blog post, etc.). The User Task List provides guidance and insight into the amount of research that will be needed to understand the technical needs of the project and acts as a starting-point for devising user roles.
Understanding User Roles
The practice of researching and setting up user personas involves understanding user needs, motivations, goals, and constraints and allows us to empathize with the way users solve problems. In their analysis, design teams sometimes focus on the who and how, but forget the why. To understand the why, explore questions like:
- Who is the user (demographics, roles, skills/knowledge level)?
- What motivates the user to perform each task?
- What are the user’s end goals?
- What user-needs are met by completing a task?
- What obstacles might a user face while completing a task?
- Are there any usage constraints to consider?
These questions enable designers to consider all possible paths a user may take to complete a task and understand all the reasons a user might have for completing that task. Creating a simple linear navigation to solve each task will only oversimplify the process, as user motivations and goals may vary depending on the specific context. For example, why does a user need to send a message to another user? A user might know who he wants to contact, or he might need to search for a user first (this might involve interaction with search filters, etc.). In other words: two directions to solve the same task. This is why understanding user goals and usage patterns is so critical to determining the best approach to solving each need.
Now that we have identified all our user tasks and roles, it’s time to pick up pencil and paper (or Apple Pencil and iPad Pro). Oftentimes, we designers are used to sketching a few concepts to help us quickly understand and put the pieces together in a visual way. We’re just wired that way. Navigation diagrams are not precisely visual representations of the UI; they’re actually a visual way to digest and consolidate requirements, user tasks, and user needs in a diagram that represents a “site map” of the product, one that groups features into modules and explores how users would navigate down each path to complete a task. Involving stakeholders and technical architects in this exercise creates a great collaboration experience while putting everyone on the same page in terms of understanding the best way to group features into modules and the most appropriate navigation strategy to pursue.
Finally, User Task Flows
Now that the team has a well-structured navigation diagram that organizes the product’s modular and navigational components, the next step is to ensure the proposed navigation also accommodates the user’s needs and expectation. Through the creation of task-specific flows, design teams can determine which criteria and tools are essential in order to streamline navigation across all processes. This exercise—and incorporating user-role research into the equation—helps designers discover where in the user’s step-by-step progress we might need to add validations, filtering, or sorting capabilities. Identifying user pain points (and gain points!) allows us to consider user abandonment, stress conditions and completion-progress-acknowledgment as we architect the user’s step-by-step progress through the app.
Following this comprehensive approach enables designers, key stakeholders, and others to understand all the necessary background information prior to getting into the hands-on UI work. Experimenting with color and font choices becomes a purely aesthetic decision, once the navigation and user interaction puzzle has been solved. Understanding user goals and navigation patterns, makes designing the layout that much easier. More importantly, the process reduces the occurrence of errors and missed requirements significantly, allowing the project to progress smoothly ahead to technical implementation.
Remember, this approach shouldn’t just involve the design team, exclusively. In fact, getting more teams involved during all of the user-discovery sessions will give engineers, project managers, testers and end users a feeling of being an influential component in the design process, and will ensure all parties are in agreement, and focused on the same goal.
Lastly, if your organization is developing an app and needs some design help, or needs help updating or extending an existing application’s UI/UX, please check out our Mobile UI/UX Design Kickstart or simply reach out to us—we’d love to help you get started.
UX Designer at Propelics