Late 2017 I worked on this joint project with my spouse, Andrew (a hard core web developer). He wanted to build a website that allowed charitable givers and charities to have a single place they could look for, start, or share donation matches.
Having just completed a bunch of research about Agile vs Waterfall workflows I jumped at the chance to practice everything I had learned.
What is Agile design? The traditional way to create a website involves the User Experience designer first deciding what content should go where and how to format it. Once that is finished she passes it along to the User Interface designer who creates color palettes, graphics, and the other visual components for the site. Lastly, this template is given to the Web Developer who codes it to life. This creation method is called Waterfall and it sounds great, right? Well…
Often the Web Developer would be handed something that looked great on paper but was completely unfit for a responsive web format. Other times the User Interface designer would be unsure of content importance and create a visual hierarchy that didn’t support the UX designer’s carefully planned layout. While both Agile and Waterfall workflows have their strengths websites and digital products are often too dynamic to be built in static chunks. Constant communication between all parties is critical and thus Agile was born.
In Agile design all three parties are deeply involved at every stage. Yes, UX takes the initial lead, followed by UI, and finalized by Development but constant discussion and feedback loops ensure mistakes are made (and fixed) rapidly.
Because this project was a very small team of two I played the roles of UX and UI designer while Andrew handled development.
My current research method involves collecting data on the site’s target demographic and then assessing what their needs might be from there. I found the average user age group who donates online is 20s-50s which gave me a clearer focus on who to design for.
Learning that 18% of online donations come from mobile devices furthered supported everything I had learned while working on my Mobile First project. Following the Agile workflow, I immediately shared this data with Andrew who agreed we should follow a mobile-first design process. (Actually, he said, “Ugh, yeah, I’ve been doing that the start.” Ok, developer.)
If I had to do it over again I would collect data from online studies AND go perusing through other donation-based sites. Once I got to the point of designing the “create a match” process I realized I had no idea what current best practices were or what other successful donation sites were doing. No reason to re-invent the wheel if you don’t have to.
Andrew and I discussed the site layout together and I created a sitemap detailing how a user would perform tasks like making a match, search, create an account, or log in.
Because we were aiming for a minimal viable product (MVP) the site was kept very basic. In the future, we plan to add more functions and content for visitors.
My next step was developing user personas and their perspective user stories. I wanted to explore the needs of both our younger tech-savvy users and equally important older users to ensure they both felt comfortable on the site.
Looking back I wish I had created a third persona for our youngest user, the 20-year-old who probably has different needs and frustrations than the more established 30-year-old and 50-year-old.
Having collected information about our users I begin to sketch out wireframes. Because of our focus on mobile devices and a slightly more mature age group, I opted for a simple layout based on flat design.
Flat Design Best Practices by the Neilsen Norman Group was an enormous resource to me as I sketched. A con of flat design is “lost signifiers”, or lost clues about what you can interact with and what you can’t. I found this very interesting because in “The Design of Everyday Things” Don Norman also talks about lost signifiers but in real-world situations. For instance, a flat door with no handle, panels or signs has no signifiers so the user doesn’t know if they should push or pull.
Because of this data, I was concerned that users might be confused about what items were pushable buttons. I happily found inspiration on the Hubble Contacts site which cleverly used an animation to help signify a button could be pushed. We drew inspiration from this as we developed the site.
As I was working on the UI side of things and picking colors and fonts for the site I settled on blue, red, and yellow. As Andrew and I were discussing this he mentioned concerns about contrast and visibility for users. I plugged the values into Contrast Ratio and of course he was right. I quickly changed the blue color to a darker shade.
This is a short but sweet example of how Agile development can painlessly nip problems right away! If I had completed all my wireframes and mockups before handing them over to Andrew I would have needed to redo a bunch of frames. It’s easier to fix issues as they arise vs massive overhauls at the end of a project.
As a side note I’ve noticed I’m much more objective about design choices when Agile is used which is awesome because then I’m less likely to be unreasonable or waste time arguing about personal preferences. Hey there, human nature!
My goals for this project were:
- Practice Agile development
- Create and publish a non-profit site
- Conduct user research
- Create personas and user stories based off of research
- Practice Sketch skills by creating mockups