UX/UI Case Study — Collaboration in Agile Design
Overview
My team was given the task to create a “simple” mobile application as a project demo to show-off our company’s development skills and attract clients. The goal of this project was to impress–both with the speed of development and with the sleekness and thoughtfulness of design. As a group of relatively green developers with little to no design experience, I was brought in to create a basic template with Angular 6 and Ionic that the team could then use as a standard when developing the many screens for the rest of the application. This being the first time many of the developers had even heard of a wireframe, much less how to take a prototype and turn it into code, I ended up not only designing for this application but working one-on-one with teams to teach the basics of web design and how to apply styles to components. With over 6 teams with 3–5 developers per team–this was easily the largest group I had ever worked with. What seemed to be at first a simple design project turned into a wonderful experiment in teaching, partnership, and learning how simplicity in design is key to agile development.
Process
From the beginning of this project, it was clear that our main challenges would be:
a) Coordinating between teams
b) Dealing with the extreme time constraints imposed by the client
In the span of a single month, we were to go from the drawing board to a full working demo of the application. It was clear from the get-go that I wasn’t going to be able to design wireframes by myself for every page and then expect the developers to be able to decipher a full design from it and be successful (or even be consistent between teams). As a result, there was a ton of one-on-one collaboration between me and the designated team leads which usually involved us sketching out designs ad-hoc as we came to each particular screen we were working on.
“If you give a man a fish, he’ll eat for a day. If you teach a man to fish he’ll eat for the rest of his life” — Chinese Proverb
There only being one of me and close to 35 developers, it was my main focus to involve the teams in their own designing as much as possible and setting time constraints on design sessions so they could spend most of their day on developing prototypes and not get behind on their projects (as well as give us time to review ideas and see design flaws early in the prototypes daily).
Template
To begin with, after receiving a concrete list of functions this app was to perform, I created a simple front page design that was to set the tone of the rest of the application. Additionally, it was used as an example for the rest of the developers (for whom many of them, it was their first time working in either Angular 6 or Ionic) to show them how to apply custom templating and styling to their own components and how to integrate SASS template variables to keep a consistent color theme.
We stuck pretty strictly to the original Ionic template for simplicity’s sake and so that developers wouldn’t have to spend too much extra time fooling with styling (which nearly everyone besides me agreed was a fate more agonizing than death). This way, we could keep to a theme that would be relatively easy to apply to each page of the application. Using Material as our obvious king, we were able to create a pretty sleek interface without going through the entire process of making formal wireframes and mockups. For a project that necessitated that we keep things moving quickly, this was key to our success. Even though, as a designer, I bemoaned taking away time from my usual meticulous design phase, sometimes being flexible is more important than being thorough when the reality is that most projects are understaffed, include design as an afterthought, and are expected to have lightning fast turn-around times.
I ended up going with a simple color palette of white, gray, and purple to draw more attention to the images in the application and not overwhelm the user with too much busyness. We decided that a bottom navigation bar would help the user be able to navigate quickly between important parts of the application (and for our case to be able to show the main parts of our app to the client efficiently). For those extra pops of color, we opted into using high-quality stock images, not only for aesthetic purposes but to get the hypothetical user excited for the destinations they could embark on through our app (no doubt, if this were a real application we would employ a travel photographer to get us those lovely Instagram-worthy shots). Instead of adding a ton of personalization with advanced styling, we used a mix of font weights/sizes to create a distinct look with our text and establish a clear visual hierarchy. These were defined clearly in our template to be reused across the application.
User Flow
With a template created, we quickly moved on to fleshing out the rest of the application. From talking with individual groups tasked with a specific part of the application to meeting with stakeholders about technical requirements, I was able to sketch our a basic user flow.
Putting a name to different pages was incredibly helpful and gave some ownership to the individual teams who went from “Team A” and “Team B” to “The Sign-In Team” and the “Entertainment Team”. Knowing exactly where they fit into the entire application gave them clarity and made it much easier for them to understand the importance of cohesion while going from page to page in the application.
With the general direction established, I met with each team and led an hour-long design workshop where–armed with sticky notes and dry erase markers–we came up with the basic layout for each team’s page(s). After each session, I created a quick pen-and-ink wireframe combining the ideas we talked about and drew on the white-board together. This was so that the teams could immediately start developing instead of waiting for me to create digital mockups.
After I met with each team, I created a “master diagram” combining the wireframes and the user flow chart I had created before. The diagram helped put into perspective just how massive this thing was that we were aiming to create–which definitely helped put a little pressure on everyone to code like the wind. But more importantly, this showed each team member where their part fits in the whole and understand how their pages flow from one to the next.
Devil’s in the Details
From this so-called “master diagram”, I would go from team to team to check and test prototype ideas (our guerilla testing group was usually the nearest developer in the office who was walking around taking a break). When problems arose, we would sketch solutions on the fly with whatever scraps of paper was nearby or the nearest unclaimed white-board. Agile was the name of the game and it was clearly established early on that being married to any single design would be impossible. While this method led to a lot of creativity and fast-thinking that could quickly be turned into code–much of the real work went undocumented and it was really easy for chaos to ensue. However, the flexibility of this approach allowed every single team member’s creativity to flow since everyone had to wear the ‘designer’ hat. Collaboration between design and development never looked so good.
Some teams required more attention than others as the complexity of the application increased (usually indirectly proportional to team size as it turned out). By keeping the UI simple, it enabled developers to focus on creating functions to solve hard problems as opposed to slaving over a stylesheet. Although there are usually dedicated front-end and back-end developers dedicated to those separate parts, in times where front-end developers are scarce having a well-defined design system is key.
Although most of the time, everyone really surprised me with their ability to take a loose idea (the original home page template) and apply it to their own site, sometimes it is necessary for the designer to set up rules for the self-proclaimed aesthetically-disadvantaged members of the group (something I failed to do in the first pass of our design). Simple rules like type hierarchy and spacing can be confusing for someone who hasn’t been trained to pay attention to those sorts of things. To keep things consistent, I would 100% recommend creating a document for every project that outlines basic style rules (i.e. 18 px spacing between each component, margins of 21 px on every side, etc… etc… ). This along with frequent design Q/A will help an app remain consistent even when people are working in silos.
Revision
Our first pass of the app was a rough one. The combination of a lack of experience between developers, the speed at which each team was expected to code, and a UX team of one resulted in something that resembled Frankenstein's monster more than a cohesive, modern application. It demonstrated a clear need on my part to spend more time with individuals to clarify designs and revise problem areas. Looking back, it might have been worthwhile to spend an afternoon or evening creating a digital wireframe (but, honestly, this might have resulted in a similar result as I will discuss in a similar project where I did just that with a large team). In the end, it is evident that cutting corners with time, design, and experience will lead to incredible learning experiences but rarely a result that the company is expecting.
To help remedy some of the gaps in the design of the UI, I took screenshots of each page of the application and for each team created an action sheet of steps to take to get us closer to cohesion. Some more digital wireframes were created, and I led a couple of workshops for specific teams whose quality was lacking in applying themes in Angular 6.
Outcome
Between the newly created artifacts and individual team meetings, I can proudly say our team got closer to creating the application we envisioned and whats more–an app I’d be happy to use to book my flights in the future. Although our laundry-list of features we were given didn’t all make it to version 1.0 of the app, our client was impressed nonetheless. This project was a gigantic challenge for the entire team and definitely pushed me as a designer to let go of perfection in favor of making a minimum viable product that just ‘works’. I would be ecstatic to revisit this app in the future to get real user feedback to define a version 2.0, 3.0, all the way to v N.0.
By keeping the user flow as one of the central focus points on the front end, even though pages may have ended up looking a little different, we were able to create something that bottom line, was functional. All the inconsistencies were in comparison an easy fix once the flow was established. We were able to connect tasks that were seemingly disjointed at first and above all kept the user’s primary needs first despite any aesthetic flaws.
We accomplished something that I had previously not been able to achieve with previous groups: collaboration and creative investment from every single member of our massive team–not one voice was unheard during the entire process. What resulted was something that addressed the needs of a diverse audience. If it was just me, perhaps the resulting app would have been exactly what a white, millennial woman needed from an airline app, but by adding so many voices we could create something that was more representational of what many different people need–something key for the success of technology in an increasingly diverse world. Even if the finished product might not have reflected all of my personal expectations of what a picture-perfect mobile airline app should look like–together we created something even better: something of nearly 40 people from different cultures, ages, and backgrounds had ownership of and were happy to create (I am lucky enough to work for a company that hires a very diverse group of people from all over the world).
Through this process, many of my own anxieties as a designer (and total control freak) were completely silenced. By giving others some of the reigns, you end up going to destinations you never knew existed. It is not always the ‘prettiest’ app that is most effective, but the one that considers the needs of a diverse group of humans. Pretty can always be polished later, involving others needs to be the cornerstone of any project to be really successful.
❤️ this? Follow my Medium Page as I continue my journey in documented my UX design journey.
Roxanne Coburn is an aspiring UX Designer and Front end Developer based in Denver, CO. She helps lead design workshops, creates wireframes, design guides for clients big and small to help bring human-centered design for companies who still might not be in the loop for how that is a key determination in the success of their products.
