Here you can see an overview of the development steps I'm used to take in most cases.
Different software, strategies, methodologies can vary widely from company to company, or even from team to team. While I have years of experience with all the most common ones in the industry, I've proven myself to quickly pick up and learn new tools and even assist in introducing them to teams for the first time.
The ability to document one's methods and thought processes is fundamental to repeat successes and avoid repeating mistakes, and allows a team to work in better synergy and with fewer indecision.
The process I feel more akin too is Design Thinking. This implies that what you're going to see in this page is not necessarily ordered by a timeline, as development is usually a non-linear and iterative journey.
It can get messy, but I'm also there to facilitate it.
VALUE PROPOSITION AND INITIAL UX RESEARCH
If we're developing a new Intellectual Property, work can start as soon as we know the basic info from its initial Value Proposition, or an outline of its functions and targeted customer segments.
When I am involved in the earliest stages of ideation and planning, I can offer vital support in presentation design and needed research - needed either for consultation by the team or pitch to stakeholders.
Elements from this phase, such as existing competitors and their customer base, or outlines of customer journeys, give a frame of reference for the imminent UX and UI work to be done.
Value Proposition and presentation to stakeholders for UA, multi-channel support platform
[I can't tell you more than that]
FOR PA EVOLUTION [RETELIT]
Even veterans of a steering committee can get overwhelmed by pure diagrams and text boxes all day long.
Some simple visualization, even at the earliest stages, can help shape the service or product in everyone's mind.
Also, we had a lot of fun making these quick panels.
Creating material for a pitch is a great occasion to immediately start looking at what people already know and like (or dislike) and start picturing your own approach.
PLANNING, PARALLEL DEVELOPMENT, and MORE RESEARCH
Perfecting an interface is a long process - and it's usually pivotal to the entire project. It's also not the only one aspect of it, nor can it be seen as the most important of all of them. But it's surely vital to start all in the same direction.
So a wireframe - or something along those lines, even a quickly drawn sketch of it -can serve us in immediately aligning the design and programming colleagues.
Even before that, the UX designer contribution can be needed in the preparatory stages of development, in defining the proto-personas, the fundamental user workflows, and initial map of the product. As far as I've seen, the timeline on this can vary depending on project scope and business value of certain elements.
The project director/product owner might require to visualise the user flow of pivotal sections of the product being developed. Defining some not-too-narrow proto-personas this early in the game could help give a common direction to the entire team at all levels.
We usually start from the supposed customer clusters from the Value Proposition, but this is also a good point to start interviewing potential users.
Directly collaborating with the programming team, we can deliver a basic, lowest-fidelity wireframe very early.
If at this point the target personas have not been better defined than in the original pitch, we can still determine a basic structure and module composition even for future dynamic content, and the programming team can start on database structuring or other components off the bat.
FOR PA EVOLUTION [RETELIT]
The design team [or just I] can then focus in progressively develop the wireframe to a higher fidelity, and start preparing for the dynamic content that will probably be studied after the definition of [proto-]personas.
A straightforward test to narrow down initial customer clusters and see where to start focusing for your v1.0 launch:
create a fictitious brand identity for an app that would do more or less what your service will do,
launch a "fake" Facebook ad campaign for said non-existing startup,
analyse the campaign interactions to see which served categories are more receptive,
and just plan accordingly.
To give context to these images, the OG project aimed at bringing real-life store catalogue online in real time, allowing you to browse their shelves from the comfort of wherever-you-are.
Feedback from potential users [be it in focus testing or other circumstances] can also allow us to immediately start steering our brand image and lore development in the proper direction.
[ OPEN PARENTHESIS
Sketching and documenting any building process is fundamental. In this page you'll mainly see the process behind UI and UX designs, but any medium has its ideal development plan behind it.
Storyboards and kinetic typography animation.
Illustration timelapse of a Rabbid fanart with proper sketching [otherwise I wouldn't even be able to draw :D].
Same thing goes for previsualization: rather than waiting for all possible material to be gathered and catalogued, we can always start making mental images concrete to make sure we're all going in the same direction - even before prototyping.
What if you have to design visual merchandising for a particular store of which you have just a screenshot of the planimetry and rough perimeter measurements?
Well, you scale the pixels to real size, measure virtually, and extrude a 3D model of it.
Not the most precise base, but it got the job done in the meantime.
Need a visual sketch of how the museum entrance is going to look like? Take a picture and get to drawing.
PROJECTS FOR BROMPTON
Of course you'll have the physical prototype of the visual merchandise tomorrow.
In the meantime, let's make sure that you might like how it's going to look.
CLOSE PARENTHESIS ]
At what point should you stop calling it a wireframe?
It can be a nuanced debate. What's important is that - already at this stage - you can start defining a design system and properly tagging styles and paragraphs. It'll save a lot of bothers for later in development.
layering and styling save lives
Of course everything I touch has proper layers, groups, paragraph and shape styles, legends, and anything else that makes design documents and presentation readable by anyone. I even comment my code when I happen to write some!
Sometimes it's not about creating all from scratch. An old platform already used by thousands of professionals might need to properly step in the millenium, or a project might be stuck in a sort of development hell.
In any case, it doesn't mean it takes less work; and in any case, UI and UX research can be the catalyst to the new spark.
A study of the current interface and an analysis of its users experience is needed. At times, even if such documentation exists, it's good to give it a fresh look before and try to catch that unbiased perspective.
For this project, as there was no documentation for the web portal to be remade, I first created a blueprint for its current state, noted the most glaring issues, and shared it with the developer who was to implement the final design.
As the developer could now dedicate their time to fixing the top-priority issues and acquainting with the wireframe, I tried to experiment with the new card view design, as the number and kind of info to be displayed not covered by the provided guidelines.
The current portal also lacked responsiveness. Here's a quick way to use the same shared file for old and new screens, and indicate in which direction we want to go.
Since the cards were fixed in quantity and metadata, I also took the opportunity to analyze its particular alphabetical distribution to create a browsing and filtering system that made sense.
While unorthodox, in some environments compromise is needed with industry standards.
In this occasion, we ended up with a high-fidelity wireframe with behavioral and technical annotations rather than an interactive prototype before coding, due to time restraints and the basic infrastructure being already online.
PERFECTIONING, RECOVERING, ALIGNING
Each project has its own trials to be discovered and faced.
Is the platform just outdated?
Are the users complaining about something - or dropping out?
Is there a problem with the deliverables, or is their development process not proving to be up to the challenge?
Products and services can require modernization on a wide range of aspects. In this case, a team had to tackle the development of a video conference solution for public administration practices without a UI/UX designer.
The next best solution was to provide them with a crash course on Accessibility, why and how it should (and must) be applied, and the basic knowledge of where the relevant reference material could be found.
As you can deduce by these juxtaposed slides, in this case we had an interface that had been developed years prior, and had not been updated alongside the core application. Not only was a functional lifting needed - it was also opportune to align the UI with the visual guidelines provided by the Government agency for digital content for public administration website and services
[since this platform was to facilitate paperwork and procedures for urban planning and development].
A more technical and detailed analysis might be needed when an impetuous leap forward is needed.
The video is actually just the interactive, animated index slide of the presentation made for the team - because not even PowerPoint presentations should ever be dull [it was actually done in Keynote, but it kinda works in PP].
As previously seen, we start defining our users or personas from the VP suppositions. Continuous development of the personas is essential in almost any project - or you might realize you need them a tad late.
No worries, though: as seen here, we can analyse what has been produced until this point [and how] and inject useful tools in the process without necessarily capsizing it - with all due compromises or crunch required.
Even in the direst of situations - having no defined audience, information architecture, or other specifics - we can roll up our sleeves rather than surrender. Because sometimes, beyond any of our loved specifics, the foundational principles of design and navigation will still help take a step or two forward.