An Ethological Approach to the Life of a Mobile App or Product:
When designing a product for a living thing I think it’s important to employ a holistic perspective. For example, when designing a product for a human, it’s best to understand the human at it’s core, and mold the product to human behavior as naturally as possible. Designing like this is most often referred to as “lean” or “human centered design”.
I think it’s very interesting, but not surprising, how closely related in theory an app is to an organism. Just as a Psychologist studies human behavior, the User Experience Engineer may study human-computer interaction in natural conditions in order to witness behavioral patterns, emotions, successes, and failures. 

An Ethological Approach to the Life of a Mobile App or Product:

When designing a product for a living thing I think it’s important to employ a holistic perspective. For example, when designing a product for a human, it’s best to understand the human at it’s core, and mold the product to human behavior as naturally as possible. Designing like this is most often referred to as “lean” or “human centered design”.

I think it’s very interesting, but not surprising, how closely related in theory an app is to an organism. Just as a Psychologist studies human behavior, the User Experience Engineer may study human-computer interaction in natural conditions in order to witness behavioral patterns, emotions, successes, and failures. 

Why we nix’d the docs: Using critical thinking and a product design sprint to move fast and get it out


At this moment in time, I would say that one of our largest endeavors over the past few months has been our ongoing adaptation of our design & development process to fit with the rapidly growing rate of hi-tech and mobile products. I am specifically referring to our internalization of the “product design sprint”. This sort of design thinking method of execution is certainly not new to humanity, but perhaps new to the recently formed and ever-expanding internet of things. Influenced by methodologies employed by Google VenturesIDEO, and the Institute of Design at Stanford, our process here atCitrrus continues to morph as we come across new research and different problems to solve.  

Embodying the journey  It’s about the ergonomics. The user and their needs. There will always be uncertainty around the creation of a product. During it’s formation and throughout much of it’s existence there will be inevitable errors and malfunctions. But this is not the crux of the matter. The problems are not the focal point, the people are. To best prepare for and/or fix inevitable errors, malfunctions, and failures we have to understand the people using the product. Basing a product off assumptions will ultimately prove to be fatal because assumptions do not not thrive on feedback and continuous discovery.  

Forced to “get over it!” 

Our product design sprint is a very speedy and efficient way to get solutions on the table and products out to be tested. In order to make deadlines, deliverables, and gain results we have to simplify. To take a few steps back and look at the big picture. To give ourselves perspective and design hoilstically. We have to get over the pixel-perfection, the "features, features, features!", potential monetization, and the fear of failure.

It’s about the product of best fit - for the user

Problems don’t exist without a person (or user) to experience them (user need), and solutions are not real solutions if they are not exposed to the problem in need of one. And in order to assess the value of a solution, you need meaningful events and reactions to that solution (user validation). The earlier on in creation and development that prototypes are tested and products are used, the more opportunity we have to iterate on usability and asses the product’s value or impact. Once we’ve assessed the value, we can scale.   

We utilize these quick sprints to gather gather a comprehensive knowledge of the problem via creative and analytic techniques (branding exercise worksheet, timed divergent thinking/sketching). We can then rapidly identify a minimum viable product (MVP), draw up a whiteboard full of potential solution(s), and push out utterly imperfect prototypes. 

We’re learning about ourselves

A few key adjectives that describe our process would be: free, dynamic, multilateral, open-ended, natural, collaborative, adaptable, speedy, inspirational, creative, wild, and challenging.

What I really love most about our product design sprint is that it’s marked by large collaborative efforts from the entire team and the Client. In order to address the feasibility, viability, and usability of (sometimes outlandish) solutions, you really need all the brains on the board. From day one, we gather a bit of perspective from the front-end and back-end development side of things, product, ux, and creative. Everyone has something to add, we all have strengths outside of our titled role. Working with a fun, sometimes crazy, goal-oriented and optimistic team with a strong penchant for delivery really gets the project going at full speed. Efficient collaboration and timely execution are skills that really just take patience and experience to master. 

Rooted in psychology

We believe in Behavior Driven Design & Development (BDD). BDD is human centered design with a backbone philosophy of ‘lean’ design thinking. Lean design is often marked by massive amounts of communication, collaboration, iteration, and feedback.  

The big-picture goal of BDD is to expose vulnerability early on and often. In other words, we want to avoid long-term error by detecting and assessing problems as they are presented. With our product design sprints we are able to quickly conduct focused iterative testing and risk assessment. Exposing vulnerabilities can surely be emotionally difficult, but doing so early on in a product’s lifecycle greatly ensures future success. 

Nix the docs

One of the most important things we always need to remember when sprinting is to focus. Speculation and documentation take too much time. This is a hands-on, highly interactive group activity that deals only slightly with individually created deliverables. We have to work together and trust everyone on the team to execute on time. We need to remind each other to be nimble, agile, communicative, and avoid over-analysis.

No matter how, wacky, unbelievable, or technically difficult the proposed solutions are, we get them out and we get results. 

Note: If you were wondering, we do deliver documents. But the papers are not the focus nor the end all be all. They simply provide  the means to capture the more important actions that take place. 

Visit our website to learn more!

Jekyll: Are Static Site Generators Easier to Use?

As a designer, it’s like a breath of fresh air to step on the other side of things for a second. It’s just too easy to get wrapped up in what you do from only one perspective. Needless to say, I needed a break from user-related things and colors and stuff so I looked more into Jekyll the other night. It looks like a super cool, "lean" way to manage and completely control a minimalistic blog site.

I absolutely love how simple it is to efficiently create content in markdown and commit to publish. I prefer this way of creating and editing content over having to go through an entire user-facing wyziwyg. So, after some research I found Prose.io and completely fell in love — its a clean and fast way to create and edit your site docs in browser. Coming from a UX designer, the UI is damn good for a “developer’s tool”.  

Trying to wrap my head around Jekyll and it’s components has not been easy though. It’s forced me to learn how to use the command line, install Ruby, and RubyGems — which was all pretty cool because my knowledge of coding consists only of self-taught objective oriented basics, html, and css.

I was able to set up Jekyll and stand up a horrendous/broken site in about 3 hours (hah) - I’m positive that the code is a complete mess but I’ll get to that later. Have a look and a giggle if you’d like http://ericajaclynstein.github.io/

Ending designer’s thought: Sketch app is to static site generator as photoshop is to Wordpress or Locomotive

Here are some resources that have really helped me to learn this thing:

Migrating from WordPress to Jekyll – Part 2: **Everything** you need to know about Jekyll

What is Jekyll?

Jekyll on Github

Jekyll Home

How to install RubyGems