Creating appealing medical software that is safe and easy to use requires the skills of both the UX Design team and the Development team. Each team, however, has certain processes it relies on that must be brought together to end up with a successful product in an advantageous time frame. For example, it can be said both disciplines use iteration, but in slightly different ways.
The UX Design team, which is composed of UX designers and human factors researchers, iterates the design through successive prototypes and user tests. The Development team, which is composed of front end and back end developers, iterates the code through successive agile sprints, where each sprint is committed to delivering a subset of production ready features.
While getting these two types of iteration to work together can be tricky, we find there are certain key approaches that make the two worlds come together effectively. In this article we would like to share five of those key approaches.
Gestalt is a fancy term found in graphic design curricula but it most generally means the whole is greater than the parts. A more exact definition from britannica.com follows:
“Gestalt theory emphasizes that the whole of anything is greater than its parts. That is, the attributes of the whole are not deducible from analysis of the parts in isolation. The word Gestalt is used in modern German to mean the way a thing has been “placed,” or “put together.” There is no exact equivalent in English.”
For example, when sculptors make a work of art from stone, they start with a block, rough out the shape, and then work down to the details. By taking this approach, the artisan can be sure when they get down to the details of a hand, for example, that the hand is in the right place and attaches to an arm! When doing agile development, you will by nature focus on, in a sense, the details of a hand. To make sure the story’s feature fits into the bigger picture properly, you need a vision of that bigger picture. This is the responsibility of the “gestalt” aspect of the design.
To accomplish this, It’s important early in the project timeline to make a complete flow and a storyboard of your app. This is so there is a vision of the whole of the app. It may and likely will change, but if it exists parts can be designed from a vision of the whole. Imagine designing a house by starting with the design of a bathroom. You might end up with a nice bathroom but without a vision for how traffic moves through the house it would be difficult to marry together the bathroom with isolated designs of other rooms and end up with something that works holistically. The same is true with software.
Takeaway: Create a vision of the bigger picture of your design early in the project timeline using a flow and storyboard. This “gestalt” approach ensures you can design the parts in the context of a vision for the whole.
Making workflows smooth and seamless to the user involves both good design and good engineering. This is especially true in medical mobile software where a user may be relatively new to smartphone technology and in need of navigating a process such as Bluetooth connectivity.
To get the best of the design and development worlds, it is essential to verify your workflows with the development team. This can be most effectively done using a diagram we call a wireflow, which is a hybrid picture that contains both wireframes of screens and logical flowchart elements where relevant. This allows designers and developers to participate in a meeting where the diagram is walked through in a way that everyone is looking at the same picture. Such a walk through is extremely effective at uncovering technical concerns in the design as well as edge cases that may not have been thought of yet. While the design team can envision a solid “happy path” flow, it is usually the development team that identifies subtle edge cases and error trapping that is essential to a good user experience.
Takeaway: Express your workflows in a wireflow diagram, then conduct a walk through meeting with design and development to make sure the workflow is technically sound and no edge cases have been missed.
Story prioritization drives what gets worked on first by development. Often in the initial sprints, the user interface dependent stories are deferred a bit so the overall UI design can mature and be user tested in advance of coding features that involve heavy UI work. This also allows the development team time to set up instances of databases and other infrastructural items that are needed for feature development.
As the UI evolves and solidifies, certain features will be readily available for implementation whereas others will require more design and testing. It’s important to capture those features that will require more rounds of testing and keep the design out front on those items. Other, more understood aspects of the design can be queued up for coding in the current or nearby sprints.
By prioritizing effectively, the design can be both iterated and user tested and be ready for coding in a synchronized way.
Takeaway: Prioritize stories to allow for sufficient design-test iterations so that when a story reaches a sprint it is solid and ready to go.
In Key #2, we discussed the importance of verifying workflows with development. Similarly, it is important to verify specialized elements, such as a particular kind of graph or data visualization that might be needed, in the design with development. This can usually be done without a formal meeting. Instead, sending a screen mockup over slack or email can start a conversation that can be extended as needed. For example, when looking at a specialized element, the developer may have knowledge of a particular widget or code library that can be leveraged to speed development. The developer may also have concerns that the design is too cumbersome to implement as presented but have alternate design ideas that are just as good and easier to implement. It pays dividends to foster this quick and informal communication whenever the design deviates from standard elements.
Verifying specialized elements up front will also enable better estimation of story points. For example, a story for a graph element may need to involve a tech spike to investigate available widgets. Knowing this up front can enable the spike to be included in the story estimate or estimated as a separate task.
Takeaway: Use informal communication to make sure specialized elements in the design can be coded in an acceptable time frame.
Ideally stories should encompass all design, front end code and back end code for a given feature. While sometimes for larger features it makes sense to break apart front end and back end code into separate stories, in these cases two related stories should be created and queued up together if possible. The reason is there can be a relationship between front end code and back end code that can have possible implications in the design. For example, what happens if data is supposed to be uploaded to the cloud from a mobile phone app but internet connection is lost? Is the user notified in the app interface or is this a behind the scenes kind of issue? The answer to such a question can involve design, front end code and back end code all at the same time.
Breaking a story into tasks can be helpful for coding vertically. Tasks enable dependencies to be identified, such as a back end API that is needed to code the front end of a feature.
Takeaway: Each user story should encompass feature design and specs for front end code and back end code so the entire feature may be developed in the agile sprint.
UX design and agile development can work well together if the five key approaches outlined are engaged. These approaches enable the coexistence of two styles of iteration, the first being the user-centered testing used by the UX Design team and the second being the agile approach to creating production ready features sprint by sprint used by the Development team.
If you would like assistance honing your own UX design and agile development processes and getting them to work better together, please don’t hesitate to contact us.
Bob Moll directs user experience and human factors initiatives for Orthogonal’s SaMD projects. He oversees user definition, use environment analysis, user workflow modeling, and interface design and development for FDA in an agile environment. Over the past two decades, Bob has worked with a range of enterprises, from Fortune 500 companies to innovative startups, designing successful new products from scratch and reenergizing existing products with improved user experiences. Bob has served clients and a wide range of their users in the financial services, education, and medical design spaces.