Interaction Design Process
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.
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.
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
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.
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.
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.
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.