UX Journeys: Lessons from What’s Thrown Away
Asking the improbable, then designing both accepted and disgarded perspectives on purpose
While most of what we do at Mindboard (@MindboardInc) is an adept jostling between qualitive and quanative data, there’s also a significant portion which happens on pure instinct. This intuition is honed through hours of successes and failures (re: the commonly quoted 10,000 hours from Malcom Gladwell), and proves itself with trash cans full of discarded persecptives.
Modernization is a distinct perspective. One where client and agent acknowledge there’s some amount of the work (process, technology, and behaviors) which needs to be reset. Through much of our work, Mindboard holds the hands of organization through these quanative and qualitive explorations. Unfortunately, those only answer what the data shows. Sometimes, the need to get outside of what is known is necessary. To this, we are willing to ask the harder questions. In a recent project, we asked a nearly impossible one.
Redesigning The Entire Flow Around Mobile-Only Interactions
In the middle of a client project, we were faced with the understanding that the design wasn’t completely locked down. From fields and layouts, to some of the transitions, our UX and UI resources, while working against Angular components, Bootstrap frameworks and Section 508 compliance, were still under shifting sands of these constraints and system flow. Within the confines of these conversations, our UX leads forward-awareness as part of understanding the intersection of these elements. To ask, “will these users be accessing this system from a mobile device,” seems a common-enough question. However, the mobile-friendly aspects of this system were shelved in order to focus on what the previously mentioned frameworks and their associated developers were most familiar with.
Because we were completed with the analysis of the existing system, we were able to visualize the entire flow of the application, along with its actors. This allowed us to create a sitemap, which allowed our data modeling team to work alongside the business analysts to understand what content needs to be where. Third-party integrations were able to be mapped and organizaed into the respective phases of the project. However, that still left us with an open hole towards what the actual user goals were. Of the many questions we put onto our whiteboard, one of them kept the dropped mobile-app perspective. So we asked, “What would it look like if the case worker only worked from a mobile device?” And then set out to design that specifc interaction.
In the linked image, you can see the approach which resulted from this exploration. Some of challenges we encountered here included:
- How to minimize the amount of text-based input
- How to include secure access as part of normative usage
- Help and Support needs to be one-touch away from any screen
- Do not rely on the mobile operating system to save content in offline/low-reliability access areas
- Answer specifically-mobile activites (actions which can only happen, or happen best in the context of handheld mobile devices)
These and other questions we made sure to encounter and make sure that it challenged answering this core question. We left alone questions around infrastructure changes, back-end implementation, and even comfort level of the case workers. We wanted to deliberately go further than the current perception of modernizing the application.
Accepted and Discared Perspectives
This was not a long exercise on our part. Spending less than a week (a few hours across several days) wasn’t much of a time outlay. What we gained though was quite important:
- We found gaps in the technical and design approaches (the UI component stack as it was implemented to that point)
- In being deliberate in the amount of input we were asking for in this concept, it allowed us to ask better questions of the integrations, validations, and inputs on the project app, especially around business rules which would drive previously unseen-data interactions
- As this was not a part of primary delivery activities, it did not get the benefit of a large stakeholder audience for viewing. We did put this before a few people outside of the context of the project, and their responses shaped some of the questions and approaches we took back to the project
- We drew positives on this prototype to clean up some of the design direction of the project app
Suffice to say, though this was a “throwaway” piece of work, going down this line allowed us to see elements of the project we would either not see at all, or only see when mobile-friendly access was more considered.
UX Journey Takeaways:
Things to consider during design explorations, and even when development is in full swing:
- You might not have all of the best options in front of you; ask off-the-wall questions, and put the realistic items into your backlog for further analysis
- If using open source frameworks, many items might change (depending on the length of your project), don’t be afraid to stick with an initial decision for components or interactions, but also understand the technical debt when you do
- Don’t stop with asking “what would better be” — go to “what would ideal be” and work backwards, removing complexity and increasing feasibilty of user-focused features
Improbable perspectives will come to light during, and even further along the project. This is not a sign of a product that has not met its goals. Exploration done throughly enough will continually inform the project, and might open opportunities for other solutions, better approaches, and even revised expectations. As a significant and intentional practice within all Mindboard projects, exploration, concepting, and the resulting deliverables enables us to embrace the improbable, and better execute on the possible.
How might Mindboard assist your organization or product team identify opportunities and gaps on their next project? Get in touch with us and let’s start that UX Journey together.
