UI/UX visual design and implementation: 3D process

The 3D process is a way of building a UI/UX interface that I have developed over the years as a way to create software within the Agile methodology. It segments the process of discovering the user's needs and provides a feedback loop. This makes sure that all parties are kept informed of the state of development.

This helps minimize development drift and keeps the teams focused on the ultimate priority of delivering software that the user wants and is also happy with. An application should work like a conversation, with the users asking questions (pressing buttons) and the application answering (giving visual feedback as to the state of what is happening).

The mantra that I have always worked by is; that there does not need to be a choice of an application having great visual design, good usability and performing well. All these requirements can be accomplished with thorough research and user input.


Meeting withh Stakeholders

Meeting with stakeholders

These important meetings kick off the process to make sure everyone understands what the stakeholder wants to accomplish and how they wish to accomplish it. The stakeholders can explain the relevant needs and issues that they need solving, be that a more efficient way to do their jobs or new functionality which will aid in driving desired opportunities.

Both the stakeholders and the developers can ask any questions as to the workings of each other’s realms of expertise.

A broad over view of the direction to go forward in can be settled upon. Time lines for the initial solution proposals can be set.

Required people: Stakeholders, Primary users, Lead developers, Developers, Business analyst, UI/UX designer

User and Business requirements

Business requirements

As this is user centered design it will entail understanding their product space and the process that they use at that time. Learning more about the users needs and the intricacies of their jobs. Questioning the users to understand what they want from the software and (almost more importantly) if replacing a current system what they do not want changed. This will make sure that they keep the user experience that they like whilst getting rid of the pain points they don’t.

The business analyst and UI/UX designer can review any information sent by the stakeholders and formulate an initial idea of the work flow to satisfy the needs required.

Based on this the developers can propose the framework that they will use and why they think it is a fit for answering the needs that the stake holders have.

Required people: Primary users, Lead developers, Developers, Business analyst, UI/UX designer

Explore and research systems

Explore and research

This folds into the previous stage. A thorough examination of what the user are working with at the present time. Also, looking at similar software and systems that could provide a more efficient way of accomplishing the job required.

Systems may already exist that are extremely similar and might only require building upon or modifications to realize the needs of the users. This has the bonus of less developer work and an already established support base.

Required people: Business analyst, UI/UX designer

Objectives

Objectives

Once the previous steps have been taken (business requirements, explore and research) the development team can reconvene with the stakeholders and users to present their range findings. Preferably multiple proposals can be put forward to the users so that they can have an active role in choosing the solution that they want to be provided to them. This can include many types of interface ideas and software solutions.

When a candidate has been chosen then the developers can present the ideas behind why think that that particular direction is best.

Once there is agreement then a firm set of objectives can be laid down and the direction of solution can be narrowed. If there are issues with the solutions presented then there has been a misunderstanding in the concepts of what needs to be done and they can be caught early and amended before too much work has been done.

Required people: Stakeholders, Primary users, Lead developers, Developers, Business analyst, UI/UX designer

Sketches and Wireframing

Sketches and Wireframes

Having already produced a set of very quick sketches to communicate critical ideas to the users in earlier stages, the rest of the user process’ and any further flows and elements can be explored and refined.

This is done with the collaboration of the users and the developers to make sure that the users are getting the functionality that they want/expect and also that the developers can actually create what is needed in a fast and efficient manner. A wire frame of the whole system (or if it is too large, key parts of the system) can be created to demonstrate the happy and sad paths and how each occurrence is dealt with. This can identify any issues that maybe a problem with the user interface. Along with this the layout of the actual screens are of enormous importance as this can quite literally make the interface unusable. A good user aids the user, a bad interface actively slows down and infuriates them.

Required people: Primary users, Developers, Business analyst, UI/UX designer

Prototype testing

Prototype testing

This adds a further layer of realism to the wire frame a prototype aids in making sure the users understand the system that they will be getting as early on in the build and design process as possible. This mitigates as much as possible the chance of going in the wrong direction.

A prototype can also be quickly altered to subtly change the solutions so that the best answer can be narrowed down to. Clear communication of what is happening is of prime importance when the user is interacting with the software and this can really only be done with a “working” solution.

Required people: Primary users, Developers, Business analyst, UI/UX designer

Detailed mockups

Detailed mockups

Once the UI/UX stages of the process are predominately done focus can be shifted to the look and feel of the software.

This may already be guided by a “design bible” which is used by the whole company or may entail creating something completely original. Whichever the case maybe be, thought has to be given on how these elements are presented. The layout has been looked at in a previous stage, the colour scheme will dramatically affect the usability of anything created. This is not only from a subjective point but also an objective, someone who suffers from colour blindness has a definite issue which cannot be ignored.

Required people: Primary users, UI/UX designer

Branding

Branding

This may affect the previous stage or if that was guided by the design department it may be quite straight forward to implement. As previously mentioned, if guidelines already exist integrating the branding should not be too much of a challenge. If the design that has been created is unique to the software then cooperation between the design department, stakeholders and designer will need to be enacted.

Required people: Stakeholders, Branding department, UI/UX designer

Work with Developers

Work with Developers

Creating mock ups and prototypes not only helps the stakeholders and users get a good idea of what they are going to receive when the project is delivered it also helps the developers as it makes sure that the focus is kept on the essentials which are needed to deliver the project. The chosen prototype will be a guide to what functionality is needed. The way that the functions are built in code is fully left to the discretion of the developers as long as the delivered item produces the results that the users require.

Required people: Lead developers, Developers, UI/UX designer

Build

Building

The UI/UX designer can do what they are good at and handle all the visual elements thus leaving the developers to concentrate on what they are good at.HTML and CSS for a web based solution or XAML and style dictionaries in a desktop application.

Required people: Developers, UI/UX designer

User feedback

User feedback

This will preferably be happening throughout the entire project life cycle so no one should be surprised about what the software will finally look/act like. But a formal review prior to deployment will make sure that everything which was in the objectives list has been addressed and that any issues which were bought up during the regular feedback sessions has been tackled and solved.

A limited roll out of the software can be used to get “real world” usage and flag up any items that might be an issue.

Required people: Primary users, UI/UX designer

Deploy

Deployment

Once user feedback has been dealt with the project can be handed to the Quality assurance team, they will test the user interactions and all functionality to make sure that it works as required. If any anomalies are detected, these items will be flagged and dealt with by the developers or designers. Then the software can be deployed to the full set of users.

Obviously there is still sometime after the deployment that bugs will arise or certain functionality will need to be tweaked to make life easier for the users but that is a natural occurrence with any project.

Required people: Primary users, Lead developers, Developers