RedLine is an internal application built for a company in the F&I industry called GSFSGroup. It is built utilizing a micro-service architecture, which might not mean much right now, but we'll come back to this later when we talk about web-componentization. The main purpose of RedLine is to replace an old, outdated technology (which I will not name here for legal reasons) with a modern, easily usable and maintainable application.
My primary role during this project is discussed in greater detail below. Unfortunately, due to the nature of proprietary software, I am limited in the screens and documentation I can display on my own personal website.
The first steps of my process are exactly what you would think. Introduce myself to the users, get to know them and their goals, and perform interviews with the Subject Matter Experts (SME's). Typically, myself and our Product Owner would meet with the users on a weekly basis to gather requirements. From here we'd get an idea about the scope of the user's request, he'd go off and do the Product Owner thing, usually writing stories, at least the basics of them, while I would get to the "drawing board." Literally.
Let's talk about the drawing board. What is it, i.e. what tools do I use?
I often start my design process on paper, I do this because it's quick, simple, and if I have an idea at a coffee shop, I can draw it on a napkin in a pinch. From there I move into Adobe Photoshop. I do this just to get a basic layout. Once I'm pleased with this I'll move into a wireframing software, like Mockflow (sample below) or Figma. Once I start in a wireframing tool, I can REALLY start to envision the scope of the project, what usability patterns I should leverage and how it will best come together based on the SME's initial requests.
I like to get the developers and the development team involved in the usability design process early. I hold, what I call, "The Meeting of the Minds." This is a discussion where all developers on the team are welcome to join (but they don't have to). In this discussion, I put the wireframes in front of the development team, solicit feedback, ideas and any thoughts they may have on additional features. I found that this meeting is extremely helpful. It allows us to identify any technical challenges with the design and it allows the developers to feel a sense of ownership over the product they will be developing.
Let's take a look at the wireframes! At this point I just touch base with the SME's to make the direction of the look, feel, and flow is on par with what they had in mind. Sometimes I make live adjustments to the wireframes; Sometimes I take notes and make more major changes at my desk.
I've found that conclusive documentation helps the development team get things right. I write, what I call, "Behavioral Documentation". This documentation outlines in words what I think my wireframes communicate visually. In the event that there isn't enough time for a full interactive prototype sometimes a static wireframe leaves too much up to interpretation. Having behavioral documentation tells the developers EXACTLY what needs to be done. Once these docs are ready, I cycle back with the Product Owner to get them attached to the correct user stories.
In public facing websites things like A|B testing, Google Analytics and the like will give you an idea of how successful your design is. I use these frequently on public facing sites. But how do you measure a successful user experience in an internal application? I like to use the timing of tasks. How long did it take a user to accomplish a task or process before the software was released vs the same tasks on the new product? In the case of RedLine it was a resounding improvement for all users that have utilized the new software.
