A UI Study

Over the past couple of weeks I made a reasonably complete UI study of the 10% Happier meditation application’s meditation challenge feature. There is a tradition in Fine Arts education of making reproductions of masterworks, and if one doesn’t have access to a designer, then this process is a valid way to push the ability to implement to good design.

Source code is available at (https://github.com/shalperin/ten-percent-happier.)[https://github.com/shalperin/ten-percent-happier.]

Step 1: Make a reasonably detailed sketch of the app’s UI

I sat down with my iPad and pencil, and made a relatively detailed sketch of the app’s UI. This is a good way to focus in on the details of the design, becoming mindful of the smaller details.

Preliminary sketches

Step 2: Implement the design as working code

A good first shot at this step might be to just re-create the UI with entirely static Android XML. However, along with this project, I was simultaneously interested in working on ‘modern’ Android architecture, so I created a little bit of backing infrastructure for the UI. It’s more ‘real project’ than mock, except for the fact that it is a direct copy of someone else’s app.

Finished UI study


What this project solidified for me is where my abilities lie with respect to the design/implementation process. You could think of copying an app as essentially working from a high-fidelity comp (comprehensive design, a term used particularly in advertising). Knowing my own capabilities a little better after this project, I understand that I’m looking for projects where this level of design is provided. Looking back on past ‘real’ projects (i.e. client work), I have a better perspective on why some things succeeded and some things failed, and part of that is the level of up front design.

A comment on “BDUF”.

Teams who misunderstand Agile principles often forgo design altogether, citing the pejorative “Big Design Up Front.” However, I think that is a perversion of what Agile actually dictates: You need design, but you might have this level of high-fidelity just for a feature, or just for the current sprint’s work. Meaning, you don’t have to have a high fidelity representation of everything (months of design, tossed over the wall to developers), but it is equally wrong to go with no design.