Worrybook.log.2: Experience is key

Worrybook.log.2: Experience is key

ยท

5 min read

You may know that in my previous post, I shared some prototype UI designs which highlighted the most essential features of the first version of the application and guided the development. This was a really useful exercise - firstly, I got intimately familiar with Figma. It's always good to have experience with design principles and tools as a developer. The product of my time doing this is by no means of the same quality or depth a professional designer might produce, but it afforded me an opportunity to learn more about that role in the greater software lifecycle, valuable forevermore.


Project coffee tracker: 5


Secondly - and this is why I'm a keen advocate of sitting down at a whiteboard before the keyboard - it got me thinking from an end-user experience perspective right out of the gates, rather than a strictly technical perspective. I learnt the value in this first-hand very early in my career, and it's something I still practice today. Just like it's important to orient and prioritise our work around the goals of an organisation we work for to deliver or enhance value using technology as the medium, understanding the end-user perspective is crucial no matter the size of the project if you intend for it to be consumed. Figuring out how a user will interact, wishes to interact, the goals they wish to achieve, and how they flow through the system is essential to building something to provide value, not just serves a function.

Give me six hours to chop down a tree and I will spend the first four sharpening the axe

โ€• Abraham Lincoln

Finally, as you'll see from the resulting design below, I was able to discover new ideas and constraints whilst tweaking those I already had to increase the value of the design and experience. For example, the worry creation screen changed slightly when I found it much cleaner to use and build with a single toggle and a descriptor of its two positions in relation to the view's function itself.

Making the Core Features Desirable

Since my perspective is that the end result is a product, I've taken a top-down approach, considering the UI and UX first. I'm quite pleased with the end product - of course, there is room for improvement, but I'm approaching this from a minimal viable product perspective whilst learning the technology itself and best practices. I've chosen to focus on building a great experience and restricted set of usable and functional features that make the application desirable when previewing and pleasant when using.

I'm no stranger to focusing on the design prior to implementation of course, or more commonly, designing during an iteration. However, the simple act of sketching a user flow, mocking a design, and then building a prototype of that design gave me a great perspective and insight as to the person who both wants to build and use this application. It allowed me to envision a feature set, refine those down to a core set that distilled the primary function and experience of the application, and focus on those. As far as exercises for knowing where you are, where you want to be, and how to get there go, this one was invaluable.

Branding it

In choosing what the application should look like, particularly as shown in the last post's initial mock-ups, I wanted to ensure that the colour palette reflected the intended goal of the application - to help toward relieving anxiety and stresses from overwhelming the mind - by selecting a flat, soft, calming colour palette as soon as the user is greeted by the applications home screen.

I wanted buttons and actions to be clear and front and centre for the user - large pill-shaped buttons which clearly direct the user to achieve the goal which a particular view they've navigated to is intended to serve, such as the dashboard highlighting the worry creation and review functionality, or the creation view ensuring the buttons to progress to saving stand out.

Finally, the application icon and in-app imagery - its identity. For these, I took to Canva and AppIcon since I needed speed and low investment of time and money. Some of you may find that the border on the top-right of the icon being broken rather bothersome, whilst the inner-content remains. I wouldn't blame you if so. Perhaps it's a design sin, but as this work reflects my beliefs, I chose that specific icon from those available intentionally. My rationale is that just like mental and physical wellbeing, we should be comfortable acknowledging, accepting, celebrating our differences and imperfections. They may never go away, but that doesn't mean they define us or make us any less valuable. This apparent design faux pas symbolises the meaning and purpose behind this project from myself.

In Summary

So, in summary, my goal in this period was to experiment with SwiftUI and achieve a functional UI with a pleasant UX, without being consumed by wiring it up to a backend to manage the ins and outs of data. That's coming later - and I'm fully aware that a significant portion of the current code enabling the UI will need re-thinking in order to be compatible with data storage, and I'm looking forward to that!

It's also worth mentioning that whilst this was the first pass at a UI and UX to progress a step above a basic prototype and aim for a minimally usable application, these will likely still be tweaked going forward - for example, simplifying various views or streamlining their UX.

Now, I'm off to start wiring up the backend to make this application truly functional ๐Ÿ‘‹

ย