How to Create HTML & PDF Prototypes Using OmniGraffle Pro

An important step in the Lean UX process is continuous validation of design ideas, especially early in your process. We are lucky enough to have a UI Engineer (shout out to Dan Hahn!) on our team who builds high-fidelity prototypes, but sometimes it is best for the designer to spend a few hours cobbling together that prototype and not ask the engineer to code and recode a prototype several times if testing the first design iteration.

The best prototypes seem the most real and finished to the test subject. If the user thinks your prototype is not live, the data is fake, he/she may be more forgiving and less critical. It is important that a table of data has numbers that look real, not a series of #### and that your text is not lorem ipsum. The best prototypes are built with HTML/CSS and JS, but as a designer, I do not code often enough to be able to churn out a full-fledged prototype for a complex feature in a few hours. Earlier on in your design process, when you need to validate your hypotheses and your general design direction, something more lightweight built from your design file or a paper prototype is sufficient.

In Prototyping: A Practitioner’s Guide, Todd Zaki Warfel does a fantastic job of covering the why and how of prototyping within the UX design process. He spends several chapters walking through prototyping with various tools: Powerpoint, Keynote, Visio, Fireworks, Axure RP & HTML. What he misses is OmniGraffle Pro. It is mentioned briefly, but never fully explained.
Continue reading

comments (0)

On RESTful API Standards – Just Be Cool: 11 Rules for Practical API Development (part 2 of 2)

I posted a few days ago about my ideas for 11 rules for practical API development. Let’s jump back in with rules 6 to 11.

6. Make it easy to understand and navigate through child objects. The fact is it can be really easy to confuse your database fields as API fields. You might have a field in your table called color_id that represents a color in the color table. Your service returns color_id and you expect your users to somehow know to hit the color service to find out more information about the color. It will behoove you to represent the color as an object since it is an attached object. Also, including a URL where the user can get more information about the color is super helpful. And if you have an extra minute, throw in the URL where they can see all the colors in the meta part of your response. For example: {…”color” : {“id” 3, “name” : “blue”}…}{“meta” : {“urls” :  [{“color” : “http://yourcoolapi.com/color/”}]}}. Use a convention like that and developers will be able to add code to automatically pull in more information about the object as well as pull all objects for a picker list.
Continue reading

comments (1)

On RESTful API Standards – Just Be Cool: 11 Rules for Practical API Development (part 1 of 2)

There are many articles floating around the internet right now about defining RESTful API standards. I’m guessing this is because Ruby on Rails makes it so easy to build an API that everyone and their mom has started building one. These articles talk about the RFC on HTTP and how REST should fit in. They outline how current implementations are “broken” and want to come up with certain “standards” for governing how a RESTful API should work. These articles make all sorts of claims about how the return type of the data should only be set in the request headers, how the obscure “PATCH” HTTP method should be used, and how doing XYZ does not follow HATEOAS. The problem with these discussions is they propose solutions that are more academic than useful.

I have a response to all of this - ENHANCE YOUR CALM!

Let’s take a step back and think: What is the real purpose of creating an API? The “real purpose” is to increase your user base by making it easy for developers to plug into your system. How does an API accomplish this? By making it simple for developers to integrate with your systems and build awesome applications on top of your systems through all of the functionality you provide. If you make people jump through too many hoops to use your API, they might just not use it – and you get zero new users from that. As a developer who has been building and consuming APIs for several years now, I have found the following rules to be practically (not just theoretically) useful for both the development and consumption of an API:
Continue reading

comments (24)