Friday, September 6, 2013

Zero To Product: Prototyping and Spiking The UI

This is part 4 of a retrospective on vizipres: A product I began and worked on for a few months.
part 1part 2part 3, part 4, part 5 , part 6, part 7

I Need A UI

Armed with the models I've created after talking with possible customers, I wanted to start exploring a UI concept. How to develop a UI is a topic that is already discussed ad infinitum on the web, so I won't go into everything I was thinking about, instead I'll focus on my key decisions & motivations.

My key motivation is to identify what-I-know-I-don't-know and then design against that until I am satisfied that the conflict I was concerned about has been resolved. For example, I'm not going to worry about how ( or if ) I need to design a log in workflow, instead I'm most concerned about having a UI that customers ( and the consumers they make content for ) will understand intuitively and feel productive using it.

What Customers Expect In The UI

When customers use an application for the first time, they are going to have to learn how to use it. When teaching something new to someone, you need to present it in a framework or context which they can understand. Think of the customer's expectations as building blocks. I need to know how to assemble those building blocks so the customer behaves how I want them to and their expectations of using the applications are fulfilled.

Above are some examples of how people solve the problem space now. When I looked at this I looked for common themes and found two big ones:
  • Content that is similar is clumped together (e.g. a heading with a description with it)
  • Text and media are often intertwined
I also consider what is not in each example and I ask why. Here are a few:
  • In the email example, why are the images and spreadsheets not embedded whereas other examples do have media embedded?
  • In the powerpoint example, why is the content not interactive?
The answer to these questions was usually because the product which the creator was using didn't offer a particular capability or the content was created in a fashion where interactivity didn't make sense. I'll have to explain that last one a bit more. Powerpoint and research papers were first used in a time when consumers did not interact with the content. Now that people are publishing research papers and Powerpoint slides on the internet for other people to consume, this content is now being consumed in a context where interactivity is expected. This is why Powerpoint slides and research papers feel awkward when viewing them in the browser.

Picking A ( Conflict ) Theme

After thinking about how current products do and do not solve the problem space, I decide that I am going to focus on how information is clumped together and how customers can easily create and manage these clumps. 

My conflict to resolve: how are customers going to clump and edit content 

To explore this conflict I just started with personal preferences - how would I want to create content like this and how would I want to consume. I'm not considering best practices really, I'm just going to start off with intuition so I can get going - later on I'll use interviews and analytics to see if my hypotheses were right.

For me, it was pretty straight forward:

As a consumer:
I want to be able to, not only consume the content I want quickly, but I also want to skip over content that doesn't interest me. 

As a producer:
I want everything right in front of me and I want to feel like I can edit my content with few (or no) intermediary steps.

To solve this conflict, I decided to go with the concept of interactive, content modules which could be hidden and revealed. My next job was to try it out and see if I liked it. 

The Spike & UI Prototype

Most of the time, when designing a UI for a product, designers will opt to create static designs, sketches and wireframes.  I, on the other hand, don't like to spend very much time doing so - and apparently other people don't too. If I do anything static, it's to help think out a problem with myself or with someone else. I believe the best thing to do is to design the UI directly in code. The two most compelling benefits of this are:
  • The effectiveness of a UI is being evaluated in the final context (e.g. web browser) - not in an abstracted context (some lines and arrows ).
  • The faster I start working with the technology in which the product will exist (e.g. HTML/JS/CSS) the faster I can know if I'm using the right technology.
Those within the XP community will recognize this as a Spike and for me, it's the best way to work. In this case, the spike also had another, very important, goal -  I knew I wanted the application to work on mobile devices ( I had learned from interviews that consumers generally expect their content to be viewed on mobile devices ).

Below you can see a video I recorded while I was creating these spikes. They didn't take very long and it was a great learning experience for my app. There are 3 versions of the UI I experimented with.


Personally, I really enjoyed the collapsing modules. After trying the different versions on various devices, I decided to go with a design similar to what is seen at the end of the video. The longer, thinner content modules made scrolling though them much easier and I could deliver a much more consistent experience between mobile phones, tablets and desktops.

Before getting into choosing a tech stack (part 6), in part 5 I'm going to talk about how I felt this was a good time to start another experiment so I could gauge current customer demand and also see if I should be thinking about narrowing down my situational segment to a particular type of customer.