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.
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:
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:
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.
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:
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.
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.
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.
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.
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.
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.