Kennedy Design, Inc.

Equal Opportunity Schools

User Research / UX Design / Visual Design

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.

User interviews

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.

Thumbnail of data uploader wireframe Thumbnail of list wireframe
Data uploader wireframes

Early sketches. These wireframes of key areas of the product were more about validating high-level hypotheses about the app than refining usability.

List wireframes

Early sketches. These wireframes of key areas of the product were more about validating hypotheses about the app at a high level than refining usability.

Constraint-based research

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.

Teacher comparison screen

One of the ideas that came out of a "magic" brainstorming session.

Forming a solution

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.

They included:

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.

Data uploader screen

One thing was clear: no other painpoints could be relieved until there was one database with up-to-date information. All emailing and local versioning of Excel documents had to stop. The first– or most “upstream”— part of the internal tool would be a data uploader that smartly sanitized the variable-format data sent from schools across the nation.

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.

Thumbnail of header version 1 Thumbnail of header version 2A Thumbnail of header version 2B Thumbnail of header version 3
Header version 1

App header, version 1. Modules listed across the top; school selected from dropdown.

Header version 2a

App header, version 2. Now matches styleguide; school-selector moved to tile bar.

Header version 2b

App header, version 2 expanded. Selecting a school.

Header version 3

App header, version 3. Data Uploader module is accessed at district-level, not school-level, so it was moved out of the school-based modules nav.

Bringing it home

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.

Wireframes and mockups

There are two main “deliverables” I often make for a project before any code gets written.

Wireframes are:

Mockups, on the other hand:

Thumbnail of sample wireframe Thumbnail of sample mockup Thumbnail of sample style guide
Sample wireframe

A wireframe.

Sample mockup

A mockup.

Sample style-guide

A style guide.

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.

Working on a non-tech team

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.

Burners on high

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.

Final render of app

Next: read about designing the TV guide of the future or hire me.