The classes you take in high school can change your life. AP and IB classes in high school mean getting into better universities, which means getting better jobs, better salaries, and more doors open.
A lot rides on your high school classes. The founder of Seattle-based non-profit Equal Opportunity Schools (EOS) saw this happen with his best friend, a capable and smart young man who was passed over for AP classes a decade before– and is still trying to catch up.
Now EOS works to make sure all students capable of taking advanced classes are given the opportunity. And it’s working. EOS is growing at an astounding rate, working with and advocating for thousands of “missing students”.
As the organization grew, the technology they had started with was being pushed to the limits. It was time for a custom solution. In the spring of 2014, the Executive Director of EOS reached out to me about designing a custom app– the "portal"– for their organization.
As with other industry-specific apps I’ve worked on, time invested in user research is invaluable– and non-negotiable. Despite the tight timetable of the app, a full two weeks were dedicated to interviewing EOS staff.
It quickly became clear that creating a custom app for EOS would be a tougher research and design problem than many.
First of all, EOS processes tended to be very industry-specific. There are no prebuilt solutions for tracking student course requests and enrollments by demographic. No out-of-the-box answers for recording outcomes of student-teacher conversations and assembly attendance for that same set of students. We could cordon off some user stories to third-party survey software, but that was it. This solution was going to be very custom.
Plus, EOS processes were far from standardized between employees. Writing software for those processes meant determining a best practice and codifying it. But there were already a lot of opinions and practices out there, and we had to narrow them down before we could build one– a potentially political issue as much as a design one.
And frankly, we didn’t even have time to do that. The earliest version of the software would need to be in place for the 2014-2015 school year. Building all of EOS’s processes into software that quickly was impossible, no matter the manpower. So we needed to determine which processes were most important to design into our solution. The rest would be added on an agile schedule.
The EOS partner teams– i.e. staff who worked with partner schools– were comprised primarily of people in two roles:
Once I had a basic understanding of the system, I immediately had to strategize. Given that there were conflicting versions of different processes and we couldn’t even build a full single version of all the processes, what would our app contain?
This was not an easy problem. On one hand, we could ask employees which processes would benefit the most from being in the new portal, but there was a complicated web of dependencies. For instance, the staff spends the better part of second semester tracking student course requests and enrollments, but those features require an enormous amount of dev work– the same work that virtually comprises some other less-important features in their entirety. And none of those things could happen without a solid way to translate and sanitize data from different schools in a myriad of different formats.
The deadline for solving these problems was tight, but building on lessons from a similar project's research, I had a few very effective strategies for quickly eliciting useful feedback.
After over a week of back-to-back interviews, the CTO, Derek, and I started thinking about how to tackle the problems we were learning about. Here was our plan.
First, I divided all functionality up into a number of “modules”. This was a carry-over lesson from my Tulare Agriculture project. Different modules would be accessible by different roles, used at different times of the year, and for different high-level purposes.
As for developing the portal, we would start with the Data Uploader, on which everything else depended. Then the development team would tackle the modules in the order that the staff would use them throughout the year. For the 2014-2015 year, we left UX contingencies– for example:
Then, in the next year, the missing functionality could be filled in, if it had subsequently proven itself high enough priority.
To combat the "everyone has their own process" problem, I would prompt the staff members with differing methods about a specific process when they were together. Then I could listen, ask questions, and determine what would work best in software.
I iterated on the design until almost the very end of the project, always checking with Derek to make sure the developer cost matched the user need.
At the end of the summer, we were ready to go. The designs were as finalized as they could be at that stage, and development was already underway. I presented the designs to the team for final feedback and to set the mood moving forward. Here are some lessons from the end of the project.
There are two main “deliverables” I often make for a project before any code gets written.
Mockups, on the other hand:
Because time was such an issue, my final deliverable to EOS was not a full set of mockups, but a full set of wireframes plus some key mockups and a styleguide. This is unusual, but it allowed for the most agility with the design right up until the very end– and reinforced to the team that this project was far from over.
Most of my projects are for teams familiar with the software creation process. This one was rarer in that it was a few developers and I embedded in a team of non-profit workers in the field of education.
Because of this, I wanted to be especially careful to set expectations as we went down a road they’d never been on.
For EOS, this was most important towards the end of the project. My final presentation laid out plans and realistic-looking mockups solving some of the biggest problems the staff had faced the previous year. Excitement was certainly high.
But it was important to remind the team that now was when the real work began. The development team would be putting in many times over the hours I did. And as the organization changed and grew, so would the needs of the portal. My final presentation was in many ways a breath of relief, but I also wanted the team to know that as good as the blueprints looked, the bulldozing still had to be done– and it would be important to be flexible and patient as this happened.
EOS was easily the hardest project I’ve ever worked on. A short timeline for a large industry-specific custom app. The stakes were high too– the team had worked with thousands of students, and was growing rapidly.
It was also the most rewarding project I’ve been on. I’ve never seen a professional environment of smarter and more inquisitive folks, and it was an honor to work hard with them towards a worthy cause.
At current, the portal version 1 is under development, I am in contact with the team to help steer the design as things change. Equal Opportunity Schools ploughs forth finding any and all students who would succeed, if only given the chance.