What’s the Best UX Deliverables Strategy in Digital Projects?

db-logo
Digital Business
  • Date Published
  • Categories Blog
  • Reading Time 4-Minute Read

Design all screens or develop them in front-end as soon as possible? Prototyping the entire project before code or just do the minimum necessary?

Design all screens or develop them in front-end as soon as possible? Prototyping the wireframe of the entire project before laying out or doodling the bare minimum?

Certainly, these are doubts that every project manager who has already planned and managed a digital project that involved the User Experience, Design, and Programming stages has already had. Finding the best answers for your project is what I particularly call the UX Deliverables Strategy.


Looking for a digital agency? Post a Project


The management of digital projects involving stages of Information Architecture and Design is as challenging as the management of scope and deadline. The rework generated because of material approvals, feedback from sponsors’ feedback at different times than those envisaged in the schedule, the subjective character that an aesthetic approval may have, are practically uncontrollable variables for a project manager.

In addition, nowadays, there are thousands of tools and methodologies to carry out a project of this type, and many of them guaranteeing the same final result in relation to the scope. So, the definition of a good UX Strategy during project planning is increasingly important so that the number of “uncontrollable variables” is increasingly smaller, and that both scope and timeframe remain within the control of execution expected.

Unfortunately, there is no formula or method ready to define what will be the best strategy for your project, and like much of project management, it must be based on good practices, your experience, and, mainly, the type of project that is running. Usually, the same strategies tend to work for projects of the same type with the same client profile.

Some points that I usually map in my projects:

#1

Customers who have a more traditional profile in the material approval stages, or who will be involved in several internal approval stages, will probably require the maximum number of screens designed for the project. Therefore, considering the premise that only part of the project’s screens will be created, could be a future problem in terms of scope and deadline.

To solve this, a good strategy goes through the Information Architecture stage, which should create as many page templates as possible, called templates, and try to adapt contents and contexts for these models.

#2

System projects will have a lot of use of forms and data tables, they should build a strategy that involves the shortest possible Design time, preferably in the creation of only a component reference screen.

My experience says this: forms and tables are the easiest elements for a Front-End Programmer to produce directly based on a Wireframe Prototype or even a Functional Specification that lists the necessary fields. So that the forms and lists do not have an aesthetic or navigation below the desired, include hours of review and QA of a Design professional in the work of Programming performed. Undoubtedly fewer hours will be invested than would be invested in the design of all forms, with a strong tendency for the end result to be the same.

#3

In the Planning stage, map the customer’s understanding of prototyping and wireframe. Preferably, show examples of high and low fidelity prototypes, and ensure with the approval points, the understanding of the expected material.

If there is no guarantee that the material approved in the prototyping stage is not the aesthetic result of the project, try to invest as little time as possible in this stage (use of mockups, low-fidelity prototypes), and involve more mixed UX / Design professionals directly in creating screens.

#4

Map from the beginning of the project which are the main devices that the project must reach (mobile, tablet, desktop, smartwatch ..). Preferably, choose the main device to determine the general style of the project, and for the others needed, create only reference screens. Designing all screens at all resolutions usually generates just a waste of time and work and does not guarantee that approvals are more assertive.

A good strategy, in this case, is to involve the programming steps as quickly as possible when the number of resolutions is very varied. Technically, it becomes more agile to replicate an entire project to a new resolution, directly in programming steps, than in Design and UX steps.

Understand your needs, compile which strategy you will follow, and do not forget to do, at the end of the project, a retrospective to assess whether the adopted technique correctly mapped the client’s profile and whether the result of quality, scope, and deadline was adequate.