Interaction Design Process

This is a longish read, scroll down if you just wanna look at the pictures
Most of Human Computer Interaction research and design follows a common script: Find out who your users are, what they care about, and what knowledge and expectations they bring into an interaction. From this, designers often create some sort of working tools to retain the knowledge of the user during design: personas, journey maps, etc. These working tools then inform some cheap prototypes used by designers to try and fail fast. At the point in the design when you feel you’re in the ballpark, designers may move to visually or behaviorally more complex mockups intended to hone visual and functional design and to refine details. These mockups then often form the basis of a prototype, and detailed specs may follow.
My process, having worked in smallish enterprise startups during their high-risk high-growth phases, is usually distilled into the following areas.

Knowing the Users

This step has to be done, but it’s not always easy. Enterprise customer/users can be tricky to access, while professional services are less so. Contextual inquiry tends to works well in these situations. Generally, this produces notes and sketches, but if I’m working inside a larger design team, or when it’s necessary to communicate users to a wider audience, I formalize these notes into personas or journeys. If I’m working with an existing and thoughtfully instrumented app there should be some useful quantitative user and usage data. Usefully interpreting telemetry/instrumentation data requires good knowledge about how it was collected. Simple metrics like “average daily users” work well for the business side, but don’t translate easily to usability.

Quick Prototypes

Quick prototyping focuses on testing the content and flow, rather than the color of buttons and other details.
Here’s a wireframe  for a mobile app used by MarkMonitor’s registrar customers to handle approval and registration of domains. It may seem like an unconventional choice, but this was created using Keynote, which made it easier to enlist PMs to test.



Here’s Balsamiq Mockup for wire framing a bigger application, in this case for scheduling a complex software rollout.

Here’s a higher fidelity version of the software rollout application showing changes to the sidebar for user feedback. Since the intended users for this application are software engineers and product managers they often use monitors 27″ or larger, but do expect to keep at least 2 windows open or in view. As a mockup this is a bit larger than usual, but is designed to show several variations.

Higher Fidelity prototype of “test in Production” Rollout

Finally, I created some visualization sketches to show how refinements to a detection algorithm eventually get to a point where they are usable for detection.

Test, Test, Test. ‘Lightweight’ task analysis

I know that my first ideas, like those of most designers, tend to suck, so finding cheap ways to test things out makes a huge impact. Depending on project durations, we can hopefully get a few iterations. Of course there are never ‘enough’ iterations but lightweight task analysis can provide crucial input. In most enterprises, many users really can’t meaningfully react to something unless they can see and manipulate their data. Being lightweight, this mockup doesn’t show user data.

Enlist and Teach Anyone With Customer Contact How to Test

In some situations I’ve handed off the protocol and mockups to PM which is one of the motivations for using stuff like Keynote, basic HTML, or an interactive PDF from Balsamiq.  In my view, PMs should understand how user testing works, and should be able to make the most of any customer facing opportunities. As a general rule it’s always good to have someone who isn’t the designer do the testing of a prototype.


Higher Fidelity/ Prototype-As-Spec

By using higher fidelity drawings for situations requiring testing nuances, or by providing reference implementations, designers can show what can be done to skeptical engineers. Since these tend to be much more labor intensive though, it’s important to work carefully to ensure engineers can pull markup, icons-as-fonts, and other assets from the high fidelity work.

Podomatic podcast page customization tool. Click to try it out!

Development Specs and Redlines

I have experience delivering both markup in tools like Invision, was well as detailed redlines to developers. Below is a detailed layout mockup for F6S, a community for startups.

Here’s a search flow interaction used to workout revisions to party search for Exigen, one of my clients. In insurance terms, a ‘party’ is a thing or person that is insuring, insured, or the subject of a claim. Some parts of this were composed as a paper prototype we could test quickly.

Summing up

Getting the right product and interactions has everything to do with knowing the users and repeatedly developing and testing workflows and ideas. When consulting I will use whatever tools will further that aim efficiently. Ultimately if the job is done right, the resulting product improves the quality of life for those users by eliminating all manner of frustration.

Current Toolset

People ask about tools. When working ’embedded’ at a customer you adopt their workflow for efficiency. Working in enterprise startups often means a certain scrappy outlook to tools.

  • Paper and pencil: Fastest way to get raw ideas out.
  • The Adobe suite: More modern tools exist but Photoshop and Illustrator have their place
  • Glyphs: Deliver icons by base-64 encoded font. Any font editor will do, I just like this one.
  • Sketch: A must for clients who choose to adopt online spec/collaboration. Much better suited to design for mobile, or responsive.
  • Online collaborative design/spec tools — I group Zeplin and Invision together here even though they have some material differences. If the customer uses them, I do too. Much better than redlined specs in Photoshop.
  • Balsamiq: mixed feelings about Balsamiq, but the lo fidelity of it comes in handy.
  • HTML/CSS/JS: for some development orgs and for some engineers, building it in markup or jumping into the dev environment builds a kind of credibility other methods just can’t. I do jump into dev as needed to get things shipping well.
  • Slack or other group messenger: my existing clients hail from SF and I’m now in Toronto…
  • Various video conference tools: if they record you can do some testing thru them. in-fact I use this more than standalone recorders as it affords a kind of one-way mirror.
  • Jira, Confluence, github: I’ve used most of the agile/bug/source code tools. stories, EPICs, issues.
  • Other unorthodox stuff: Keynote and PowerPoint can be useful for quickie tests on mobile.
  • Excel & PowerPoint (or docs): for test results and presentations.

I don’t use many A/B test tools as split testing works best with simple interactions and large numbers of users. In working on a project for building such tools, one comment I clearly remember was the need to A-A test first do determine if the likely advantage or disadvantage would be lost to statistical variation. Folks love to use A/B to optimize small things but the smaller the change the harder it becomes for it to rise above a certain level of noise.