Valuable UX-Driven Design

Who should be concerned with valuable User Experience Design?

Architects, Software Architects, Developers and Stakeholders at the very least , identified as those who are interested in building better customer engagement and within time constraints. User Experience Driven Design or UXDD is performing a task-oriented analysis or requirements and designing the most effective architecture for the tasks to be implemented. The driven part of the UXDD term relies crucially on that specific order of actions.

The Leaning Tower of Pisa Wasn’t Meant To Lean

Refactoring, fixing, determining both liabilities and cost can help prevent an unstable foundation. Legacy Code is essentially any code inherited from someone else that works even though nobody really knows how and why, much like the leaning tower of pisa. Legacy Code is related to critical functionality that is not convenient to halt or dismiss thus making it problematic to replace such a code with something patterned more modernly.

The World Is Being Revisited and Re-engineered Through Sapient Use of Code

Is there any new revolution in sight?

Much like how we believed the sun circled the earth and discovered otherwise – we once believed the user would circle the software/App or digital tool and be changed by it. Rather, now we understand currently that it is the tools that orbit the user and adapt to their needs.

We collect and acknowledge requirements, design and elaborate a model, choose a set of technologies and execute with programming. This process of transforming data doesn’t always reflect the complexity of the business world or its needs. In order to successfully reflect, the new revolution calls on us to stop modelling ideals and hoping for the best and start mirroring the world around, translating the needs through code or whichever interactive medium the user would experience through. This is what saves us from the Legacy Code very quickly after the inception of a project is committed.

Project management for such innovative approaches have been susceptible to lack of communication, organisational culture, pressure, lack of domain expertise, skills, judgement or, just bugged technology.

Ariane 5 and The Inertial Guidance System

Self-destroyed after 39 seconds of launch, losing 7 million pounds into the Ariane 5 rocket due to a bug – the kind that is in programming, not hanging off a strand of hair.

The unnecessary code added had resulted in a calculation that generated an error. Nobody had a chance to ever test it in the air. The fundamental problem is not the lack of exception handling and testing but rather the pressure of deadlines, stakeholders and operators that resulted in a copy/paste working solution.

The Ariane 4 computed fine with the variables but the lack of time to test with the Ariane 5 considering the shockingly tight dealines led to this disaster. This Antipattern is known as Architecture by Example. For the most part, Architecture by Example is a result of pressure. At the time of the Ariane 5, the Executive VP of Lockheed Martin, Frank Lanza, stated that software is crucial.

Brian Foote and Joseph Yoder coined the term “Big Ball of Mud” which is a euphemism for software disaster. A Big Ball of Mud is a software system that grows badly and controlled and is really hard to fix. It’s an intricate system full of hidden dependencies, duplicated portions of code and unclear identification of layers. It is nearly always the result of teamwork and doesn’t happen overnight.

The things leading up to cause a BBM are:

• requirements/features

• precision of estimates

• requirements churn

• role of management.

Stakeholders describe what they want, often omitting details and delivering their requirements in a convoluted way. Developers misrepresent the ongoing business and in good faith build what they understand. This poor communication fails, not because lack of talking, which isn’t more effective with an increase of it unless the method of communicating is changed.

The canonical pattern to this is the generic information given by stakeholders who may not be able to distinguish between a basic log-in page and a detailed page, that uses social media to authenticate the log-in & have that communicated explicitly to the developers. The nitty gritty details are what the developers want most in order to implement an accurate quote of the effort. The stakeholders usually have a fixed cost but fixed meaning at least as high as the cost of the worst known worst-case scenario. The new emerging trend in opposition to the canonical approach is the #NoEstimates approach which isn’t to eliminate estimates, but to focus on an quicker way to get the software actually needed.

Estimates require a big upfront design and therefore frozen requirements. The butterfly effect in any additional requirements then changes the context of the existing system and may trigger a different dynamic. Requirement churn as mentioned previously in leading up to a BBM, is what this is called in software, and can only be addressed in continuous refactoring.

UXDD is not going to save the world. It’s simply a design approach that places a lot of emphasis on the presentation layer. Talk is easy and cheap while customers want concrete and visual ideas of the final product in it’s usage and function. Requirement gathering uses visual immediacy which catches missed points, focuses on actions and matches the front and back-end desires for the user.

The two architecture roles are the Software Architect and the UX Architect. The Software Architect faces the painful truth of requirements collected from the business needs to build the best possible domain layer. The UX Architect collects usability requirements to build the best possible UX for the presentation layer. The two roles may be carried out through one Architect who operates through both sides in one project. Ideal user-machine interaction is established by the UX Architect and is tested through usability reviews with recordings of users in action, analysis of body language and time monitoring of operations for improvement. The goal is catching any design and process bottlenecks as soon as possible.

The Philosophy of User-Experience Driven Design in Three

1. Create screens and iterate on the layout until they are loved by the users.
2. Make actionable buttons on those screens that trigger appropriately orchestrated business workflows. The key thing here is that the screens abstract all the data that goes in and out of the system for each use case.
3. To code workflows using required piece of business and data access logic.

These three steps to UXDD do not take place sequentially not alternatively – there are two distinguishable sprints. One to build screens and one to build systems. UXDD is based on a two-phase waterfall, each developed in a fully agile manner. The economics of UXDD are low-cost design on the front-end because the screen face, iterative design of the front-end is actually pretty quick and cheap since it doesn’t require any coding plus leads straight into back-end implementation.

Time spent on wireframes are usually seen as an avoidable cost. A more interactive prototype when the storyboards aren’t enough calls on Axure. Fixing a multi-layer system that’s closer to being fully developed is much more cost-effective than iterations at the first call for accurate user expectations.

ROI of UX-Driven Design

BALSAMIQ uses a PowerPoint-style sketching and limited story-boarding. Sketches can be saved as PDF files which is good for quick turnaround.

The limited storyboarding however is not always accurate and has a risk of multi-phasing or misunderstandings of analysis.

AXURE (and similar) uses a Designer Studio which is HTML based, UX expertise helpful and doesn’t require development skills.

The rich storyboarding is available in HTML/JS ready to share for the customer to experiement. The experience is realistic – the code is not. It provides a realistic experience and sharing of prototypes.

UXDD Summary

UXDD is a top down methodology to design software systems, assessing through wireframes and prototypes, this method devises the ideal architecture for the job and the processes as described. No persistence data model is created and then adapted, it works the other way around. This is why events must be understood leading to Event Sourcing and CQRS as architectural patterns. The domain analysis leads to identifying bounded-contexts, which are the foundations of microservices.

It’s nothing new. UXDD wraps up popular buzzwords and effectively makes them meaningful keywords.