“I challenge you (to duel)!”

background

Just kidding. It’s not a duel at all. My friend (let’s call him Fred) posed a design challenge. He came to me with an idea he wanted to try coding for practice. The idea was to come up with a financial budget web app to help people become fiscally responsible or at least aware of their spending habits. Fred listed out the basic functions it needed to have and gave me 5 hours to see how much I could get done.

Hour: 0 - 1

Fred and I quickly brainstormed ideas to flesh out the basic functions he listed for me. During this time, we also sketched in a frenzy to explain our ideas to each other.

Hour: 1 - 2

Based off the brainstorming list and unreadable sketches in the first hour, we condensed, ideated, and finalized what I was going to design for him. It wasn’t reasonable to expect a complete prototype that displayed all happy flows, errors, and possible functions within the timeframe we had. But I thought it would be important to get the major flows and interactions designed.

The finalized list included:

  • Dashboard with analytics/graphs to visualize the monthly budget, spending, etc.

  • Spending history - add, edit, delete capabilities

  • Ability to set maximum spending budget per month

Hour: 2 - 5

I slapped on a couple of graphs for the dashboard homepage. Obviously, these graphs can be changed, added, or tweaked, but I wanted to include at least a couple as high fidelity placeholders. The spending history page probably had the most complex logic and functions. The user needed the ability to add new entries, as well as edit and delete them. Each entry should be grouped into a category/subcategory that would make graphs and analytics easier to read, and I included a description capability for ease of understanding and, most importantly, remembering.

I also wanted to include basic UI styles and other actions, so my friend would have an easier time coding and understanding my designs. In addition, this helped create a mini design system for me to use in Sketch and for other potential projects.

lessons learned

This was really fun! Maybe a tad stressful because of the timeframe. But the timeframe ensured that the most important features were there first. Whatever extra time I had I devoted to the next important items. I think the most important lesson here was prioritization. What are the most important functions and features that have to be included? Like it won’t even be a product if these aren’t present and working. Then, secondary priorities that enhance the user experience of the primary priorities. And lastly, tertiary priorities that are more like nice-to-haves. These priorities were determined by the stakeholder (Fred) and his business goals.