In my previous Blog Posts I summarized the process of transitioning to an Agile based UX design and how the SCN team has integrated UX into the Development process. In this Blog post I will provide an overview of how we are changing the management of UI specifications and communicating UX to the design team.
One of the main difficulties encountered in typical UX design is efficiently and reliably conveying the UI /UX design requirements to the development team. Traditionally the definition of the UX/UI is defined in a set of comprehensive wireframes, mockups and design specifications which combined can run to hundreds of pages. While these documents are good at conveying the overall UX vision, and can be useful in initial planning of the UX, they tend to be inadequate for conveying to the developers the details they need to effectively implement the UI. Additionally despite the best efforts and planning UX solutions change and evolve as the app is built and tested. The subsequent process of updating wireframes/ mockups to reflect design changes and passing them on to the development team for reimplementation tends to create frustration amongst the team and introduces further delays into the development process.
One of the main advantage of an agile process for me as a UX designer is that it acknowledges this upfront, and with its short iterative development cycles provides us the opportunity to quickly adjust designs as the application is developed. This flexibility makes it easier and more practical to move away from the overarching "final" design blueprints, which only create a roadblock that makes it more difficult for stakeholders and developers to get past, as the design requirements of a project shifts. The alternative to this has been to rely more on user stories to define UX tasks and features and developing a UI Framework for conveying design specifications.
Using User stories to define UX tasks
Within the SCN team we have moved away from relying on detailed design documentation for communicating UX/UI requirements towards using User stories and "just in time" mock-ups/wireframes. By just in time I mean that I do not attempt to resolve the entire UX for an application before the development starts but tend to develop UX solutions as we progress in the development of the application. The development of the UX stories occurs in a design sprint which occurs 1 or 2 sprints before the feature is implemented. Typically the design sprint allows for the UX solution to be discussed with the product owner and business representative as well as the development team in order to help define an appropriate solution. The sprint generally ends with the creation of a follow up ticket, either by the Product Owner or myself which defines the expected functionality. The proposed UX solutions are defined using user stories, which describe the end user actions (and not the design) and supported by mockups or wireframes to clarify UI details. The tickets also define the expectations and assumptions about the funtionality.
By using User stories to convey the UX through describing the expected interaction patterns that a user will undertake the team is able to focus on how a specific feature works from an end users perspective without having to flip through design documentations to find how how the UI for a specific element is created. By defining this as needed in the tickets and user stories developers are more likely to have the information they need for implementation in one place. More importantly though is that the initial implementation focuses on the development of the functionality. How it should work from an end users point of view. In order to manage the details of the UI, typography, button colors, list styles the ticket is typically handed over to the Front end developer ( in this case myself) to implement the target UI. In order to improve the efficiency of this process we have begun to develop a front end Framework which will act as both the UI foundation for SCN applications as well as the UI/UX guideline.
Using component based design frameworks
Within the SCN team we are moving away from relying solely on design specifications to convey UI details and have begun to implement a UI framework and set of design guidelines which defines both the overall design direction as well as specific UI components. Using frameworks is of course not a new idea and has been implemented within other projects within IT and have proven to be extremely useful in simplifying the management of the UI.
By implementing the framework and set of design patterns we are able to provide a more useful tool to the dev team for implementing the UX of the application. The framework we are currently implementing provides a central repository of assets, styles and guidelines which is a living reflection of the UI and UX requirements for the social platforms. The framework defines the typography, Colors, styles, list elements, form elements as well as third party functionality like select 2 to enable more flexible select form components. This framework is supported by a style guideline which defines the layout, and class names and html elements to use for defining the UI. The main difference is that the style guide is part of the framework and as an online document can be quickly updated and centrally accessed by the entire team.
The intention is that the design guidelines will be incorporated into the framework and will be a living document that is updated regularly to reflect future design changes. This will also hopefully mean that future updates or changes to UI elements can be undertaken on the central SCN design framework and updated across the various applications reducing the need for custom updates to each application.
