User Experience and the Big Picture, Part 3: The Solution

Design

A lead UX designer leads the Design stage, but it also heavily involves the client’s product owners. We seamlessly evolve the inception model into a high-fidelity design model, using a single Axure Team project in the cloud.

This realistic model either defines or applies the client’s brand style guide. We do any visual design working directly within Axure whenever possible—which is very often! When necessary, we create discrete assets in tools such as Adobe Photoshop, XD, Illustrator, and Premier. Then we import and refer to all of these assets in the Axure Team project. This approach is in keeping with our key goal that there is only one design artifact.

We model the red-route user journeys in much more detail, then optimize them by gathering stakeholder feedback and conducting usability testing, using Lean or UCD techniques.

We capture key design patterns using Axure’s powerful library functions, so we can reuse them during both the Design and Build stages. This makes the software inherently more usable, and we can produce our designs more efficiently.

As we iterate the design, key members of the Build team ensure that it is viable or even optimal from a technical-architecture perspective. This also lets the technical team upskill on key technologies they know they’ll need during the Build stage.

Creating this design model typically consumes between five and fifteen percent of the project’s budget. It is expensive because, by this time, we know very accurately what the clients will receive at the end of the project, how much it will cost, how long the project will take, and how we’ll build the software. Again, our investment more than pays for itself downstream, and that’s why this approach is common on large, civil-engineering projects.

Once again, the client signs off on the design model before we enter the Build stage, which is similar to waterfall. However, unlike traditional waterfall, the model is concrete and unambiguous, so the vision is clear to all stakeholders!

I do not concur with the popular approach of using one tool for conceptual design—for example, Sketch or Adobe XD—then another tool for detailed design. Instead, at AxStream, we use the same tool, Axure, throughout the design process, so everything stays in one place. Therefore, we avoid wasting time or introducing errors by rekeying or doing data conversions across different tools. Of course, I am familiar with the argument that tools such as Sketch are faster for conceptual design. However, I can offer two counter arguments:

1. I have not found that tools such as Sketch or XD are faster if Axure is in the hands of real power users.
2. Spending time synchronizing multiple tools typically obviates any time savings from using simpler tools, even if Axure is not being used by power users.

Build

One of our agile project managers leads the Build stage, with the support of a development lead.

We break the Axure design model down into one- to four-week sprints, within the same Axure Team project. So there are no translation errors, and everyone is working on the same page, literally!

During each sprint, we further model the design where necessary. We also add any necessary supporting documentation—using Axure’s powerful, multi-user annotation and diagramming tools. We do this in enough detail that the developers can code the design without encountering any ambiguity. This model often includes exception handling, edge cases, and content.

Because our development teams receive some specialized, but relatively fast training, they are able to code directly from the Axure project.

During each sprint, we apply the coding principles and efficiencies of agile—such as competitive and points-based coding. Rework is minimal because we’ve already fixed any issues and validated the holistic design and technical architecture during the Design stage.

During user-acceptance testing (UAT), we capture and address bugs using Axure’s screen-capture, annotation, and stakeholder-feedback tools. The only other tool we use during the Build stage is an agile project-management tool for driving the code output—such as Jira or Redmine.

Conclusion

In this article, I’ve necessarily provided only an overview of our method. In practice, there are typically many complex variations on the core method. Plus, each project has its own nuisances and unique challenges. This is particularly true in the case of large projects if the Build stage must begin before the Design model is fully complete. However, we have developed a number of robust strategies for handling these situations, and the method has proven highly effective and efficient in actual use.

While one might argue that the waterfall aspects of this method constitute a weakness because they limit our ability to accommodate requirements changes during the SDLC, looking at this issue pragmatically when working on real projects, we have not found our method any better or worse than purely agile methods. Although it is true that stakeholders sign off on the design prior to the Build phase, we have developed some subtleties in the method and its execution, so the Build stage can accommodate the requirements changes of any typical project. Of course, the fact that our method ensures that we’ve defined the requirements well during the earlier stages of the project is of great assistance in our achieving this outcome.

Further, our experience is that requirements’ changing during the Build phase often does not result from there being truly new or changed requirements. Instead, these requirements have emerged from poorly defined or undefined requirements that always existed, but were never captured or communicated properly. In this sense, the method I’ve proposed in this article