Function vs. Form: why design matters more than ever in code

Since I began teaching myself how to code back in 2014 I’ve gone through many phases of improvement in my development process. Whether it was the early stages of understanding recursive algorithm design or completing your first project there are many milestones to be gained. However none of these milestones impacted my ability to create projects I was proud of more than shifting from functional to design oriented thinking.

Let’s begin by defining functional-thinking. Functional thinking is, by my definition, thinking wholly in terms of what an application does or could potentially do. It answers the what and the how. For instance, in one project I tried to develop a smart contacts mobile application. One problem that needed solving for was allowing 2 users to exchange contact info (vcards) with 1–2 taps. My initial approach? Throw in NFC (near-field communication), bluetooth, and QR codes just because I could. I would go on to spend weeks of precious dev time researching technologies, building minimal prototypes, and trying to come up with workarounds when faced with technical shortcomings (all eyes on you, bluetooth). The end result of my early mornings and late evenings on this work? Impressive functions and a bloated, disjointed user experience.

Now for design oriented thinking. Design oriented thinking is a state of mind where you are insistent on the purpose of the application being simply defined and the experience of using the application succinctly framed. As you are designing solutions to problems, you do not only need to know how to solve the problem. You must know how you want the solution to feel to the end user. Alternatively, you may have a goal intrinsic to the process of creation such as developing a specific skill or creating an impressive item for your resume. No matter the purpose of the application or the experience you want it to convey design oriented thinking will enable you to achieve your purpose.

I started to become more design oriented as I began working closely with a designer. He introduced me to the design community via books and website recommendations. Below are some of the resources I used to start thinking like a designer.

• www.smashingmagazine.com
• Design Systems by Alla Kholmatova
• Inclusive Design Patterns by Heydon Pickering
• Smashing Book #5
• The Design of Everyday Things by Don Norman

From these books, websites, and personal development projects I developed the following framework that turned creating projects into a more rewarding process as I was frequently satisfied with my end products.

1. What is the problem you are trying to solve / the goal you are trying to achieve?

Determine the purpose of the application. This can be intrinsic to the creation of the project (EX: I want to develop a single page web application using NodeJS, Angular, and PostgreSQL to improve or exhibit my coding skills) or it can be external to the creative/development process (EX: I want to make a task-list app to help me keep track of the tasks I want to accomplish).

2. What features would help solve this problem?

General:

Features are what solve individual portions of the problem. These features must be tied together intuitively to help the end user solve the problem.

Strategy:

1. Ask why for problems

Evaluate why the current way of doing things exists. Is there a good reason that the current solution was created and maintained up to this point? If so know the strengths and weaknesses of existing solutions whether that is software, paper records, manual labor etc.

2. Ask what can be solutions

What can be different to remedy the problems clarified from the “Ask why”? If you find there is good reason to give this new solution a shot, continue. If not, consider new problems. Trust me, there are still plenty out there.

3. Prioritize feature by importance and achievability

General:

Now you must prioritize your features so that you maximize the results for your effort. When starting a project it is good to have early wins to generate some momentum. Then focus on important and challenging problems. When frustrated or stuck for too long sprinkle in easier tasks to bolster your efforts.

Strategy:

Full disclosure: I’ve not used this system explicitly as instructed below, but realized my older processes of prioritization basically operated as below

Maximizing features:

1. Make a list of all your features and then create another copy
2. Assign values to one list such that the feature you most want to do or are simplest (whichever way you wish to frame it) are ordered 1 (being to most desired) to n (being least desired)
3. Assign values to the other list such that the most important features is rated a 1 (being the most important) to n (being the least important).
4. Take an average benefit of each development task. Determine which features are most important and which features are most readily completed by the items with the lowest averages. This way you ensure you are getting the most benefit for the least amount of work.

4. Find a mantra

You need a simplified way to remind yourself of the feeling you want your application to create. This needs to be simple enough to be memorable, but specific enough to force you to make decisions. This was not my creation, but unfortunately I cannot remember who’s book or article led me to this vital strategy.

I have literally used this on every project I’ve done since the start of 2018. This methodology helped me make decisions large and small for every aspect of the applications.

Strategy:

3 adjectives or descriptors:

1. Choose three words that describe how the application should feel. These descriptors must be tightly tethered to the root purpose of the application.
2. For every uncertainty you have while developing the project, frame the decision as contributing to one or more of the those descriptors. You want every decision and every feature to maximize its contribution to solving your targeted problem.
3. Repeat ad nauseum

Now that we have the framework laid out I will give a brief example of two different use cases:

Mini Case Study 1: Oliver’s Table

Note that this particular topic was covered in depth in my escaping the font rabbit hole article.

Purpose: Create a template concept website for a restaurant

3 Descriptors: Fresh, Responsible and Elegant

Situation:

When choosing fonts for this template I knew I wanted to pair a serif and sans-serif font. Just by browsing through free font repositories I found the sans-serif font Muli. I knew through my initial reaction that this was the font I needed.

Next I needed to find a serif partner for Muli. I found 6 solid contenders, but none of them grabbed me as Muli did. So I developed a system of judgement for fonts that took into account stroke, proportionality and symmetry.

This helped me provide justification to myself for my decisions and allowed me to narrow the field from 6 to 2. Then I was stuck again for a bit until I looked back and remembered my descriptors: Fresh, Responsible, and Elegant. With these in mind I realized that Muli strongly characterized the fresh and responsible nature of the brand. This meant that I needed to chose the more elegant of the two options. This heuristic quickly provided a solution now that I had a descriptor that needed representation.

Mini Case Study 2: Artollo

Purpose: Explore the use of shapes and create a robust clean musician theme for electronic artists

3 Descriptors: Geeky, Sophisticated, Clean

Situation:

Full Disclaimer, a majority the geekiness in this template comes from the copy I wrote. Particularly the musician bios ;)

Creating the unique “Artollo” styling of the IBM Plex Mono font relied heavily upon the mantra finding. This kept a constant tug of war between the three descriptors. I ended up going with the italicized IBM Plex Mono as it provided some visual uniqueness (Geekiness) to help round out the extremely pleasing and clean font Dosis.

Hopefully those mini case studies provide guidance on how you can use this framework to ease your product ideation and associated frustration. If you would like to hear more about how this framework has been used be sure to subscribe and be on the look-out for full blown case studies. Additionally there is a plan in place to write an article about how this decision framework would operate in an Agile environment, scrum etc.

I look forward to hearing from you all in the comments and to hear how you’ve learned to create projects as well!