In Part 1 of this three-part series, I described some problems with the software-development lifecycle (SDLC). Then, in Part 2, I shared some of the key lessons I’ve learned during my more than 30 years of experience in IT. For the last 25 years, I’ve focused on improving the efficiency and effectiveness of the SDLC, considering the key role UX professionals have to play in making such improvements.
Over the last five years, these learnings have led to a new method that we have been honing at my company Ax-Stream. I believe that this new method is now at the cutting edge of software-engineering methodology. Naturally, this method incorporates all of the key lessons I discussed in Part 2. In doing so, it integrates aspects of Lean, user-centered design (UCD), agile, and waterfall, along with some novel thinking and highly advanced use of our modeling tool of choice, Axure. As Figure 1 shows, this new method comprises just three key stages: Inception, Design and Build.
One of our conceptual-prototyping specialists leads the Inception stage. However, the team is multidisciplinary and involves stakeholders from all parts of the client business, as well as our business analysts, business-process engineers, and leaders for the Design and Build stages.
Using Checkland’s basic approach, which Improvising Design summarizes well, we work with the client’s leadership team to combine strategic analysis and business analysis with both market and user research to develop a root definition for the project. This one- or two-page document encapsulates all of the project’s key elements, and we use it as a reference in every meeting to ensure that everyone stays focused on the vision.
We prioritize key user and business requirements, then translate these into red-route user journeys that drive a design-thinking process. Using marker pens and whiteboards, we generate a number of concepts—including key screens—that meet the requirements and drive a solution, so our thinking becomes concrete soon after we develop the root definition.
Working closely with the client, we model a number of these concepts in Axure RP Pro and conduct iterative testing using Lean or UCD techniques such as guerrilla usability testing, formal usability testing, user cost-benefit analysis, and focus-group research.
Based on the test data, we select, integrate, and evolve these concepts into a single inception model. This encapsulates the software’s scope, its key features, and the principles on which it works. At this point, all of the stakeholders clearly understand and agree on the conceptual solution. They then sign off on the inception model—rather as they would for a stage in a waterfall approach.
We typically spend about five percent of a project’s budget on this stage, which is a core feature of our left-shift thinking, whereby we identify problems early when they are much cheaper and quicker to fix. This approach ensures that there is one concrete vision across all stakeholders. Our investment more than pays for itself downstream, which is why this approach is common on large, civil-engineering projects.
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:
I have not found that tools such as Sketch or XD are faster if Axure is in the hands of real power users.
Spending time synchronizing multiple tools typically obviates any time savings from using simpler tools, even if Axure is not being used by power users.
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.
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
Ritch has worked in UX design since 1995. He has a BA with Honours in Creative Design, an MSc with Distinction in IT-Computing, and a PhD in Human-Computer Interaction (HCI) from Loughborough University’s HUSAT (HUman Sciences and Advanced Technology) Institute. Ritch has lectured at the Masters level in five countries—on user-centered design, UX design, usability engineering, IT strategy, business analysis, and IT development methodology. He also has numerous internationally recognized qualifications in IT-related training and education. He has published many HCI articles and was on the editorial team for the Encyclopedia of HCI (2007). Ritch has led major UX design and user-centered design projects at Bank of America, Vodafone, Thomson-Reuters, and Dell Computers. His international experience spans 15 countries. Ritch presently heads Ax-Stream, an approved Axure training partner. His work currently encompasses Axure training, advanced Axure prototyping, usability and acceptability testing of early conceptual prototypes, coaching and mentoring of senior UX designers, and strategic UX work—integrating UX design and user-centered design into agile development methods and moving organizations from second and third generation to fourth generation prototyping methods. Read More