Kennedy IxD

Tulare Agricultural Products

User Research / Interaction Design / Visual Design

Skinnee field directory app

In the fall of 2013, I was contacted about doing design work for an agricultural company in California. The proposal was quite large: the company needed an entire suite of applications to address both their general business needs (sales, product orders, inventory, etc.) as well as unique business logic specific to their industry and company (such as their innovative fertilizer scheduling system, their database of custom products, and more).

At the time of the proposal, the company's methods of tracking this data were disparate: Excel spreadsheets, Access databases, photocopies, or pen and paper. Skinnee would be the application to unify all those and provide one copy of the truth to all TAP employees.

Oh, and one more thing— the entire project was constrained by the upcoming growing season.


I agreed to do this project on the condition that I could travel on-site as soon as possible. Without getting as deep an understanding of TAP and its processes very quickly, this would be all but impossible to finish on deadline.

They agreed, asked if I was available the next week, and soon afterwards I found myself thrown into the first stage of the design process.

User Interviews

My on-site was a 3-day whirlwind of user interviews. User interviews in the board room, user interviews on the warehouse floor, user interviews in the R&D station.

The following principles guided my user research:

Thumbnail of inbox sketch Thumbnail of inbox mockup Render of inbox mockup
Sketch of inbox solution

Thinking of inboxes. Upcoming Events was represented with an inbox-like table of items that the user would have to tick off. If they cleared their tasks for 2 weeks, there'd be a friendly message.

Mockup of inbox solution

Final mockup. After much deliberation on which columns to display, in what order, and how to show special cases, we finalized the mockup.

Render of inbox solution

Inbox render. The final solution incorporates multiple rounds of feedback on every aspect— and presents a miles-ahead solution to the phone calls and photocopies it replaces.

Mockup of the order form

Heavy duty forms. In order to adequately meet the preferred workflow of the warehouse manager, we'd have to revamp some pretty hefty forms.

The last step in the user research phase was to break up the Skinnee application into modules, which would be the logical division of the suite for security/permissions and UX purposes.

The final list for the first phase contained:

UX Iteration

The Skinnee system displayed a myriad of objects— from people and organizations to fields, seasons, and crops. While no one expects editing a contact's phone number to be the same experience as adding a field to a ranch, we wanted the general interactions with Skinnee data to be familiar and consistent.

In other words, we wanted to balance intuitiveness and consistency.

I want to talk about two related principles we landed on.

Edit in place

The debate here was whether a screen displaying details about a certain object (a farm, a client, anything) should have a separate edit mode screen or whether each control should be editable individually.

We settled on the latter, for a few reasons:

Thumbnail of normal control Thumbnail of hovered control Thumbnail of clicked control
Normal control

Normal data. This is the standard appearance of data in Skinnee— in this case, an office's address and phone number.

Hovered control

On hover. There are strong click affordances that appear on hover.

Clicked control

On click. A simple click renders the data editable. To save, press ENTER or click outside the control.

Displaying child data

The data models required by Skinnee were complex. A farming company is composed of ranches, which in turn have fields and irrigation stations. Fields have temporary planting instances, recording what crops and varieties are there (though some of these are quasi-permanent). Planting instances and schedules (oh— and farming companies) can have schedules governing what is applied to them and when. And that's just the beginning

So here's the question: do you display a farming company's ranches the same way you display a ranch's fields or an irrigation station's schedules?

If so, do you use a list? A table? A map? A calendar? And should you edit the child object in a separate screen? A new tab? A popup? An accordian?

The answer, of course, is it depends. But for what it's worth, we found tables and popups to be the overall best solution. Maps were too expensive and required extra panning/clicking and calendars are a poor way to represent events whose timing is not known more accurately than the week level.

Thumbnail of data shown in a table Thumbnail of hovered data shown in a table
Data shown in a table

Tabular data. Tables are customizable and familiar.

Hovered data shown in a table

Easy to edit. Just like other controls on the page, each table row affords editing on hover.

Ultimately, different types of child data did get slightly different displays. A farming company can have many offices, but since there are rarely more than 3 per, and each comes with multi-line data (the address), it made less sense to display them in tables. Same went for other address-centric data, like billing and shipping addresses.

Address data

Just a few addresses to display? No table required.

Every table in Skinnee is different. Some are editable; others aren't. Some have auto-totals rows and built-in filtering controls. Others don't.

The net effect, however, is a consistent way of displaying and interacting with hugely disparate types of data.

Lessons

Time to iterate doesn't scale linearly.

Most of my design estimations were fine— but I ended up coming way short on one of the bigger modules, in particular. What was happening there?

Essentially, feedback on each module is applicable to either a.) one and only one part of the module b.) many screens of the module— essentially a percentage of it. Type B feedback for larger modules is more likely to trigger a bunch of additional Type A changes, simply because there are so many things interacting— hence the non-linear timeframe.

Fortunately, it never blocked the dev team, but in the future, I will add a larger percentage buffer for wireframing larger projects that require lots of feedback.

Agile saves time.

Because of the project size, I thought it would make the most sense to write a spec for each module, which the devs could comb over and decide exactly how they wanted to break up the work between them.

In the end, it turned out that it was much quicker for me to enter the design straight into user stories and bugs. Plus, since cross-module work was grouped logically, changes that would've required editing a half-dozen specs ended up requiring editing a single story.

Some things are out of my control

Despite doing a lot of design work that would provide immense value to TAP, larger teams have dynamics of their own.

Unfortunately, at the time of posting, the project is on standby for reasons out of my control and unrelated to design.

Please check back for updates.


Next: read about designing an app that makes you good at giving gifts.