Designing for Projects
Some designers, like me, work in our daily routine under two types of scenarios, products, and projects, where the projects are composed of a group of products in which I also work.
In this “article," I will share part of my experience and how I have been solving the challenges we face when working on projects.
Projects Scenario
The stages described at a high level when working on projects are:
- Pre-sales: sales analyzes the market and potential customers, performing demonstrations of the current products and solutions, and understanding when the following opportunities will come, as well as working on preparing answers to specific requests from different customers, such as Expression of Interest (EOI), Requests of Information (ROI), Request for Proposals (RFPs), among others.
- Sales or Project: when our proposal has been a complete success, pre-sale turns into a project.
Let's talk about Pre-sales:
The following diagram (a very rough and high-level diagram) shows the process of pre-sales (pre-sales stage) and award of a project, where I frame the most relevant pain points, at least the ones I have faced in my working life under this scenario when someone from the UX team is not involved in this phase.
On this high-level journey mapping, I'm only showing the creation of technical information (technical envelope), not the financial data that must be prepared and delivered as part of the proposal.
High level and summarized pre-sales journey, when we are preparing proposals or other requested documents.
Description of the pain point n. 1:
Wireframes of the solution that need to be included in the proposal are created by the Business Product Manager (BPM) without the involvement of the UX designer and sometimes even without the rest of the project team.
Result:
- The BPM could be committing the team to do something that is not possible in the project’s timeframe.
- The wireframes added might not be keeping consistency across the solution.
- The BPM is not an expert in using the components of the product design guidelines or design system of the company.
Description of the pain point n. 2:
Demos of the solution that need to be shown to the client are created by the Support Manager, without the involvement of the UX designer and sometimes even without the rest of the project team.
Result:
- The demo could sometimes create expectations on functionalities that will not be 100% developed, as shown during the demonstration. On the other hand, it adds pressure and commitment to the team to do something that is not possible in the project’s timeframe.
- The developed demo might not keep the consistency across the solution.
How did I solve these pain points with which I used to deal in this phase?
First, analyze the consequences of not involving all the people who should contribute to the project from the beginning. Then, create awareness of this situation and finally, propose solutions, just as I would do to solve the challenges of a particular user.
As a result of these ideation processes, I created a methodology or process to ensure the necessary people were included in the pre-sale stage.
The diagram below shows the processes I added to our previous pre-sales process.
Pre-sales added processes
Now let's talk about the stage of development of the project:
In the case of project development, the biggest challenge is the deadline, which in some way, depending on the point of view, limits creativity ... or at least that creativity that I call "futuristic creativity.” Suppose you see it from a different point of view. In that case, you might think that, on the contrary, you must be even more creative and skillful to be able to set your creative mind to designing something that eliminates the users' pain points and is achievable in the timeframe you have.
You have to be a real expert in this scenario since you have to solve the user's problems. At the same time, you must take into account that you must follow the contract and keep consistency not only in the product but across the entire solution, as well as manage the deadlines, the feasibility that it can be developed in the available time, having to comply with the laws of the country where that project is being carried out and that you are not gold plating, this last one is the number one enemy of the projects.
I created a team dedicated to analyzing the current process to work more efficiently, mainly headed by the UX team. I put several agile projects/product development methodologies, such as agile and lean UX, on the table. The team discussed the current process and how to adjust it. I evaluated the pros and cons of each idea, and after extensive discussions, I reached agreements to which we all committed.
Let's separate our project development process into two significant phases:
- Requirements analysis phase: in this phase, the initial project understanding sessions are carried out, that is...
- The project kickoff is carried out,
- All the project information is collected,
- The requirements are analyzed at a high level, in which the possible gaps between the existing product and the product to be delivered to the client are evaluated,
- The users and stakeholders are listed and analyzed,
- The customer interviews are prepared, and
- The development and execution of the project are planned at a high level (the deliverables, the milestone, and the resources involved are reviewed, and the budget is analyzed, among others).
- Design and development phase: the team starts the execution of the agile methodology of project/product development. In this phase...
- The user stories are written,
- The backlog is refined,
- The planning sessions are carried out,
- The sprint and tests are executed, and
- The review and retrospective sessions are also carried out.
The idea is not to redesign the entire products involved in a solution each time you have a project but to identify the gaps between your products and the requirements. It would help to focus first on those functionalities that do not comply because they are "incomplete" or because the flow does not match exactly what you identified the user does.
In other cases, the criticality is led by the number of users that will use specific functionality or the complexity of a flow.
E.g., You have a project in which 50.000 operators will be registering voters or citizens. The flow and the complete functionality of registering voters or citizens could be critical because you want the process to be fast (usually there are requirements related to performance, as the average registration time per citizen must be less than 2 minutes), but most importantly, to be accurate...so this functionality will be one of your top priorities to analyze and design.
In the example, I have many users using that functionality, so you do not want to rely on training for this. In some cases, this flow could also be complex. During their registration process, I had some clients that captured 90 fields of information, picture, ten fingerprints, and signature.
The following diagram shows some processes I added to our agile development methodology.
Project development added processes
We use the SCRUM methodology to develop our products and adjust the products to projects. But now, with the UX being involved in the process, this is what "our" diagram looks like.
Original diagram downloaded from internet. Source: https://javafromdev.com/2017/09/15/scrum-methodology/
In this process, I add new inputs, like the customer journey, blueprint, and the wireframes created during the pre-sales phase (the wireframes we included in the proposal).
Now in the backlog, I have epics and user stories and the UX tasks that will be included or covered in this project.
I will also show you what a 2-weeks sprint looks like when there are UX tasks, from the backlog, on that sprint. This is important because the whole team must participate in the ideation process. This participation may affect the points calculation of user stories delivered by the engineering or development team on that specific sprint. They will invest part of their sprint time in the ideation meetings.
2-week sprint with UX tasks
I could say a lot more, but this is already long!
Each company has its idiosyncrasy, culture, and way of doing things. The purpose is always to improve the way we achieve our goals because there is always room for improvements everywhere...well, this is what we are doing. I hope my experience gives you ideas that could be put into practice.
This is something we are trying... fortunately, so far, it is working, but as usual, we are iterating our processes and getting better every day!
