Designing Software From the Outside In: Putting Visuals First
When you lay out UI ahead of time, buy-in happens faster. You can envision end products and understand it better—read more about the importance of putting visuals first.
As a younger design engineer, I once heard, “if you can’t picture it, you don’t understand it”, which forever changed my approach to software development. It’s somewhat of a double-edged sword, however, as it’s crucial to encapsulate not only the vision or process within an application but also a UI that’s intuitive and not limited or constrained by that vision. And then when you add in today’s rapidly developing and changing software-centric environment – along with the complexities of tools such as web interfaces, mobile applications, and cybersecurity – graphical representations of problems and solutions become much more complicated but, at the same time, also a necessity.
Without these representations, the whole process often leads to a UI/UX that probably won’t meet preconceived expectations, which can also be due to a lack of effective communication or imagination when gathering the requirements. What I’ve learned is that it’s vital to flesh out and refine the requirements into only the pure, necessary interactions.
This is where pictorial representations of the operational requirements come into play. They are made to clarify the scope and scale of any problem to be solved. Being able to see how they align to requirements allows stakeholders to clearly and accurately explain goals and objectives to the rest of their team and ensures everyone is on the same page. When approaching projects in this way, I’ve experienced a surge of constructive interaction, which helps point out any misrepresentations to form a cohesive user experience.
Storyboarding: Going Beyond Agile
The biggest learning lesson is that we need to completely change our approach to software engineering lifecycle and go beyond agile methodology. This ensures that the vision and goals are understood before designing complex systems or data structures. To do that, we rely on storyboarding to prototype out the broad strokes of the overarching UI – focusing on workflow and data entry – resulting in a “back of the napkin” demo version of the completed app but lacking all functionality.
And due to the rapid nature of storyboarding, demos are often produced with a deliberate lack of cohesive UI design by varying layout and data input types throughout. By giving the end-user a larger swathe of potential design elements and structures, we can isolate what elements they prefer while also exploring ones they don’t.
From that horizontal slice, you can deep dive into one feature and implement a vertical slice of functionality within that prototype app. The combination of the broad (but shallow) UI with a (narrow but focused) implementation allows the user to experience how the app could look and function given that design.
Telehealth as a Use Case
This recently happened when working on a telehealth solution with the VA where we used two similar sections in the app to demonstrate the uses, advantages, and disadvantages of UI switches versus segmented controls. When we conducted a demo during an onsite mock simulation, we quickly discovered that UI elements (e.g. the buttons) had to be much larger, more widely spaced, and less prone to missed taps when moving around the hospital, versus sitting and testing it from a desk.
Had we not gone through this visual exercise, we wouldn’t have identified those elements that needed to be changed. Trying to make changes or incorporating requirements further down the road would’ve caused headaches, wasted resources, and delayed the launch of the app.
The Three Elements of Storyboarding
That all said, I like to ask three questions at the beginning of a project, which helps clarify the requirements needed, and ultimately inform the storyboarding process. I’ve touched upon them in the above, but at a high-level, they ask:
What do you need? This establishes engagement from the very beginning where you can fully understand the end goal, not just a list of requirements. You’re including all stakeholders at the onset and are able to incorporate all of the positive and negative feedback to refine it.
This pertains to the physical environment from where this application will be primarily used – whether intentional or not. That means testing it out in real-world scenarios – such as the aforementioned VA example – to determine how the UI should adapt or shift to things like lighting conditions, movement, internal v. external networks, and the specific type of device being used.
How do you need it to work? This is a hybrid of the first two, but it definitely warrants a separate – yet related – conversation. It brings the what and the where together in a way that illustrates potential use cases. In other words, let’s talk through the first two to walk through the last. The how is directly tied to the agility and flexibility needed for the execution to be successful given any number of scenarios, (whether they are planned or not).
When you’re able to ‘tell the story’ and layout the UI ahead of time, the buy-in happens so much faster because you can envision the finished product – you understand it from the very beginning. This is especially true when designing for a broad audience of non-technical users; the form is vital to the app creation process so you know an end result is a tool that people will want to use – you’re starting with user-focused behavior and then wrapping your data around that. So, contrary to popular belief, it is the form that drives the function; it does not follow it.
Source: https://dzone.com/articles/designing-software-from-the-outside-in-the-importa
